Selbst entwickeln oder kaufen: Sollte Ihr E-Commerce-Unternehmen eine Tracking-API entwickeln

Die meisten E-Commerce-Unternehmen sollten eine Tracking-API kaufen oder integrieren, anstatt die Infrastruktur für die Sendungsverfolgung von Grund auf selbst zu entwickeln. Eine Eigenentwicklung kann sinnvoll sein, wenn die Transparenz über Sendungen eine strategische Produktfunktion ist, das Unternehmen über erfahrene Backend-Entwickler verfügt und langfristig die Pflege der Carrier-Integrationen übernehmen kann. Für die meisten Teams verkürzt eine etablierte API die Markteinführungszeit und verlagert anspruchsvolle Aufgaben wie die Normalisierung von Carrierdaten, die Zuordnung von Status, Wiederholungsversuche und die betriebliche Überwachung auf einen spezialisierten Anbieter.

Bei dieser Entscheidung geht es nicht einfach um die Kosten eines API-Abonnements im Vergleich zu Entwicklergehältern. Es geht darum, wer die laufende Arbeit übernimmt, die erforderlich ist, um uneinheitliche Carrier-Daten in zuverlässige Kunden- und Betriebserlebnisse zu verwandeln.

Was eine Tracking-API tatsächlich erfordert

Eine einfache Integration mag unkompliziert wirken: Eine Sendungsnummer senden, einen Status erhalten und diesen auf einer Bestellseite anzeigen. Eine Tracking-Funktion auf Produktionsniveau ist jedoch umfassender. Das System muss möglicherweise den Carrier identifizieren, Aktualisierungen anfordern, unterschiedliche Ereignisnamen interpretieren, verspätete oder fehlende Antworten verarbeiten, die Sendungshistorie speichern und dem übrigen E-Commerce-Stack ein stabiles Format bereitstellen.

Sie muss außerdem in die Geschäftsabläufe passen. Trackingdaten können in ein Auftragsverwaltungssystem, Kundenbenachrichtigungen, eine Support-Konsole, eine gebrandete Tracking-Seite, Lieferanalysen oder Regeln für das Management von Ausnahmefällen einfließen. Eine API, die Daten zurückgibt, aber nicht zu diesen Abläufen passt, kann dem Unternehmen weiterhin erheblichen Integrationsaufwand hinterlassen.

Auch Sicherheit und Zuverlässigkeit gehören zur Entscheidung. Die OWASP API Security Top 10 weist auf Risiken wie fehlerhafte Autorisierung, uneingeschränkten Ressourcenverbrauch und eine unsachgemäße Bestandsverwaltung hin. Eine Build-Entscheidung sollte daher Authentifizierung, Zugriffskontrolle, Ratenbegrenzung, Protokollierung, Überwachung und Reaktion auf Vorfälle umfassen, anstatt sich nur auf den ersten erfolgreichen API-Aufruf zu konzentrieren.

Eigenentwicklung oder Kauf im Überblick

Wann eine Eigenentwicklung gerechtfertigt sein kann

Ein internes System sollte ernsthaft in Betracht gezogen werden, wenn mehrere der folgenden Bedingungen erfüllt sind:

• Das Unternehmen verfügt über ein großes Engineering-Team mit Kapazitäten für die Erstentwicklung und die laufende Wartung.
• Die Transparenz über Sendungen ist ein zentraler Bestandteil des Produkts, Marktplatzes, Logistikdienstes oder operativen Vorteils des Unternehmens.
• Das Unternehmen benötigt Anforderungen an Datenverarbeitung, Aufbewahrung oder Bereitstellung, die verfügbare Anbieter nicht erfüllen können.
• Die erforderliche Anzahl an Carriern ist relativ begrenzt, stabil und gut bekannt.
• Das Unternehmen betreibt bereits angrenzende Infrastruktur wie Ereignisverarbeitung, Observability, Support-Tools und Data Governance.
• Volumen und Nutzungsmuster machen das Geschäftsmodell eines Anbieters nach einer ausführlichen Gesamtkostenanalyse ungeeignet.

Auch in diesen Fällen ist der Aufbau eines vollständigen Carrier-Netzwerks ein erhebliches Vorhaben. Die erste Version kann eine begrenzte Anzahl von Carriern unterstützen, doch eine Erweiterung bringt neue Formate, Authentifizierungsmethoden, Service-Level, Ereignistaxonomien und Sonderfälle mit sich. Ein Unternehmen sollte das Projekt nicht allein auf Grundlage des Aufwands genehmigen, der für die Erstellung eines Endpunkts zur Abfrage von Sendungsnummern erforderlich ist.

Wann der Kauf normalerweise die bessere Wahl ist

Der Kauf ist in der Regel die bessere Option, wenn Tracking wichtig ist, aber keine differenzierende Produktfunktion darstellt. Dies ist bei Einzelhändlern, Marken, Marktplätzen und Softwareunternehmen üblich, die zuverlässige Sendungsdaten innerhalb eines bestehenden E-Commerce- oder Logistik-Workflows benötigen.

Ein Anbieter kann besonders wertvoll sein, wenn das Unternehmen über mehrere Regionen hinweg versendet oder mehrere Carrier nutzt. Der kommerzielle Wert besteht nicht nur im Zugriff auf einen Endpunkt. Er kann auch ein normalisiertes Antwortmodell, carrier-spezifische Wartung, Dokumentation, Überwachung und Support umfassen. Der genaue Umfang variiert je nach Anbieter, daher sollte jede Funktion anhand der offiziellen Dokumentation und während eines Proof of Concept überprüft werden.

17TRACK bietet eine Tracking-API an und veröffentlicht eine API-Dokumentation für Entwickler, die eine Integration prüfen. Dies ist eine relevante Option für Unternehmen, die einen Multi-Carrier-Trackingdienst bewerten möchten, anstatt jede Carrier-Verbindung selbst zu implementieren. Mithilfe der Dokumentation sollten die für ein bestimmtes Projekt geltenden Carrier, Endpunkte, Ereignisfelder, der Authentifizierungsansatz, Nutzungsgrenzen und kommerziellen Bedingungen bestätigt werden.

Die verborgenen Kosten einer Eigenentwicklung

Interne Entwicklungsprognosen berücksichtigen oft die erste Version, lassen aber den anschließenden Betriebsaufwand außer Acht. Eine realistische Aufwandsschätzung sollte Folgendes umfassen:

• Onboarding von Carriern und Änderungen an Carrier-Schnittstellen.
• Datennormalisierung und ein versioniertes internes Ereignismodell.
• Abfrageintervalle, Wiederholungsversuche, Timeouts und die Verarbeitung doppelter Ereignisse.
• Webhook-Verarbeitung, wenn externe Ereignisse verwendet werden.
• Verwaltung von Ratenbegrenzungen und Datenverkehrskontrollen.
• Datenspeicherung, Aufbewahrung, Datenschutz und Löschprozesse.
• Überwachung veralteter Sendungsdaten, ungewöhnlicher Antwortraten und carrier-spezifischer Fehler.
• Support-Tools zur Untersuchung von Sendungsausnahmen.
• Tests anhand realer Sendungsstatus, einschließlich zugestellter, zurückgesendeter, stornierter, verspäteter und teilweise aktualisierter Sendungen.
• Dokumentation und Verantwortlichkeiten, wenn die ursprünglichen Entwickler an anderen Aufgaben arbeiten.

Ein sinnvolles Finanzmodell vergleicht die vollständig eingerechneten Kosten der internen Verantwortung mit den wiederkehrenden Kosten des Anbieters über den erwarteten Planungszeitraum. Berücksichtigen Sie Entwicklungszeit, Cloud-Infrastruktur, Qualitätssicherung, Sicherheitsprüfung, Support, Reaktion auf Vorfälle und die Kosten verzögerter Markteinführungen. Gehen Sie nicht davon aus, dass eine niedrigere API-Rechnung automatisch niedrigere Gesamtkosten bedeutet.

So bewerten Sie einen Anbieter für Tracking-APIs

Definieren Sie vor der Auswahl eines Anbieters das betriebliche Ergebnis, das Sie benötigen. Ein Anbieter, der für eine kundenorientierte Tracking-Seite geeignet ist, erfüllt möglicherweise nicht die Anforderungen einer internen Event-Pipeline mit hohem Volumen. Stellen Sie die folgenden Fragen.

Passung zu Carriern und Regionen

Listen Sie die für Ihr Unternehmen relevanten Carrier, Dienste, Länder und Sendungsarten auf. Überprüfen Sie jeden einzelnen direkt, anstatt sich auf eine allgemeine Aussage über eine breite Abdeckung zu verlassen. Testen Sie die in Ihren eigenen Bestellungen vorkommenden Sendungsnummern und Ereignisstatus.

Datenqualität und Normalisierung

Prüfen Sie, ob die Antwort die von Ihren Systemen benötigten Felder enthält, etwa den aktuellen Status, den Zeitpunkt des Ereignisses, sofern verfügbar den Standort, die Identität des Carriers, sofern verfügbar Informationen zur voraussichtlichen Zustellung und die ursprüngliche Sendungsnummer. Bestätigen Sie, wie der Anbieter mit unbekannten Carriern, widersprüchlichen Aktualisierungen, doppelten Ereignissen und Statusänderungen nach der Zustellung umgeht.

Integrationsmodell

Prüfen Sie Authentifizierung, Anfragegrenzen, Antwortformate, Fehlercodes, angebotene SDKs, das Verhalten der Sandbox und die Versionierung. Wenn Ihre Architektur ereignisgesteuert ist, überprüfen Sie das Verhalten von Webhooks, die Signaturvalidierung, die Verarbeitung von Wiederholungsversuchen und Zustellgarantien, anstatt anzunehmen, dass jede API gleichwertige Ereignisfunktionen enthält.

Zuverlässigkeit und Support

Fragen Sie, wie Vorfälle kommuniziert werden, welche Supportkanäle verfügbar sind und welche Serviceverpflichtungen vertraglich festgelegt sind. Eine öffentliche Statusseite oder Dokumentation ist hilfreich, ersetzt jedoch nicht die Prüfung der Servicebedingungen und des Eskalationsprozesses des Anbieters.

Kommerzielle Bedingungen und Ausstieg

Verstehen Sie, ob die Gebühren von Anfragen, verfolgten Sendungen, Nutzern, Funktionen oder einer anderen Kennzahl abhängen. Bestätigen Sie den Umgang mit Mehrverbrauch, Mindestverpflichtungen, Aufbewahrung, Exportoptionen und die Folgen einer Beendigung der Geschäftsbeziehung. Preise und Limits können sich ändern. Halten Sie daher die Version und das Datum der bei der Beschaffung verwendeten kommerziellen Informationen fest.

Ein praktischer Entscheidungsprozess

1. Definieren Sie das Geschäftsergebnis. Entscheiden Sie, ob der Schwerpunkt auf Self-Service für Kunden, Supporteffizienz, Lieferanalysen, operativer Kontrolle oder einer Kombination daraus liegt.
2. Ermitteln Sie die erforderlichen Carrier. Berücksichtigen Sie aktuelle und absehbare Carrier, Regionen, Dienste und Sendungsvolumen.
3. Erstellen Sie einen Mindestdatenvertrag. Legen Sie die Status, Zeitstempel, Identifikatoren, das Fehlerverhalten und die Ereignishistorie fest, die Ihre Anwendungen benötigen.
4. Schätzen Sie die vollständigen Entwicklungskosten. Berücksichtigen Sie Wartung und betriebliche Verantwortung, nicht nur die anfängliche Entwicklung.
5. Bewerten Sie mindestens einen Anbieter anhand derselben Testfälle. Verwenden Sie repräsentative Sendungsnummern und dokumentieren Sie Lücken, anstatt allgemeine Marketingaussagen zu bewerten.
6. Führen Sie einen produktionsnahen Proof of Concept durch. Testen Sie Wiederholungsversuche, Verzögerungen, Carrier-Änderungen, ungültige Nummern, doppelte Aktualisierungen und Annahmen zum Spitzenverkehr.
7. Wählen Sie einen Fallback- und Ausstiegsplan. Speichern Sie die Daten, zu deren Aufbewahrung Ihr Unternehmen berechtigt ist, kapseln Sie den Anbieter hinter einer internen Schnittstelle und dokumentieren Sie, wie ein Ersatz eingeführt würde.

Der Fall für einen hybriden Ansatz

Eigenentwicklung oder Kauf ist nicht immer eine dauerhafte Entweder-oder-Entscheidung. Ein hybrides Design kann eine externe Tracking-API für die Carrier-Anbindung und Normalisierung verwenden, während geschäftsspezifische Logik intern verbleibt. Die interne Schicht kann Regeln für Kundenbenachrichtigungen, die Zuordnung von Bestellstatus, Ausnahme-Workflows, Analysen und die Schnittstelle zum übrigen Stack übernehmen.

Diese Anordnung begrenzt die Abhängigkeit vom Anbieter, ohne dass das Unternehmen jede Carrier-Integration pflegen muss. Sie schafft außerdem einen stabilen internen Vertrag, wodurch ein späterer Test eines zweiten Anbieters erleichtert wird. Der Nachteil besteht in zusätzlicher Architektur- und Datenverantwortungsarbeit. Daher sollte die interne Abstraktion fokussiert bleiben und nicht zu einer zweiten Tracking-Plattform werden.

Empfehlung

Für die meisten E-Commerce-Unternehmen empfiehlt es sich, die Carrier-Tracking-Funktion zu kaufen und nur die geschäftliche Logik selbst zu entwickeln, die eine Differenzierung schafft. Entscheiden Sie sich für eine interne Entwicklung, wenn das Unternehmen einen dauerhaften strategischen Bedarf, einen überschaubaren Carrier-Umfang oder besondere Kontrollanforderungen sowie einen glaubwürdigen langfristigen Betriebsplan nachweisen kann. Entscheiden Sie sich für einen Anbieter, wenn Geschwindigkeit, geografische Breite, geringerer Wartungsaufwand und eine planbare Bereitstellung eines Tracking-Erlebnisses wichtiger sind als der Besitz jeder einzelnen Schicht.

Der sicherste Weg besteht darin, die Entscheidung anhand eines repräsentativen Proof of Concept und eines Gesamtkostenmodells zu treffen. Bestätigen Sie vor einer Verpflichtung die tatsächliche Carrier-Abdeckung, das Datenverhalten, die Limits, Sicherheitskontrollen, das Supportmodell und die Ausstiegsbedingungen des Anbieters. Wenn diese Prüfungen erfolgreich sind, ist der Kauf in der Regel der effizientere Weg, einem E-Commerce-Team zuverlässige Transparenz über Sendungen zu bieten, ohne die Carrier-Wartung in ein dauerhaftes internes Produkt zu verwandeln.

FAQ

Ist die Entwicklung einer Tracking-API günstiger als der Kauf einer solchen?

Nicht unbedingt. Eine Eigenentwicklung kann Anbietergebühren vermeiden, doch das Unternehmen bezahlt weiterhin für Entwicklung, Infrastruktur, Tests, Überwachung, Support, Sicherheit und die Pflege der Carrier-Integrationen. Vergleichen Sie die Gesamtkosten der Verantwortung über den für Ihr Unternehmen relevanten Zeitraum.

Was ist der wichtigste Grund für den Aufbau einer Tracking-Infrastruktur?

Der stärkste Grund ist strategische Kontrolle. Eine Eigenentwicklung kann gerechtfertigt sein, wenn Tracking eine zentrale Produktfunktion ist oder wenn das Unternehmen Anforderungen an Daten, Bereitstellung oder Workflows hat, die ein externer Anbieter nicht erfüllen kann.

Was sollte ein Proof of Concept testen?

Testen Sie reale Carrier und Sendungsstatus, einschließlich verspäteter, zugestellter, zurückgesendeter und ungültiger Sendungen sowie doppelter Aktualisierungen. Testen Sie außerdem Authentifizierung, Ratenbegrenzungen, Wiederholungsversuche, Fehlerantworten, gegebenenfalls das Webhook-Verhalten, Datenzuordnung und das Verhalten der Integration, wenn ein Carrier vorübergehend nicht verfügbar ist.

Kann ein Tracking-Anbieter ein individuelles Kundenerlebnis unterstützen?

Häufig stellt der Anbieter die Daten bereit, während das E-Commerce-Unternehmen das kundenorientierte Erlebnis und die Geschäftsregeln verantwortet. Bestätigen Sie die verfügbaren Felder, den Zeitpunkt von Ereignissen, Branding- oder Darstellungsfunktionen und die Integrationsgrenzen, bevor Sie davon ausgehen, dass ein bestimmtes Erlebnis enthalten ist.

Wie kann ein Unternehmen die Abhängigkeit von einem Anbieter verringern?

Verwenden Sie einen internen Datenvertrag, kapseln Sie den Anbieter hinter einem Adapter, bewahren Sie zulässige Sendungshistorien auf, überwachen Sie die Datenqualität und dokumentieren Sie ein Verfahren für den Austausch. Vermeiden Sie es, anbieterspezifische Felder in jeder Anwendung offenzulegen, sofern sie nicht tatsächlich erforderlich sind.

Quellen

• 17TRACK Tracking API
• 17TRACK API Documentation
• OWASP API Security Top 10
• RFC 9110: HTTP Semantics