Informationen zum Umstieg von Client-seitigen Anbieter-Tags auf die Ereignisweiterleitung.

Es gibt mehrere zwingende Gründe, das Verschieben clientseitiger Anbieter-Tags aus Browsern und Geräten auf einen Server zu erwägen. In diesem Artikel besprechen wir, wie ein clientseitiges Anbieter-Tag dahingehend bewertet werden kann, dass es möglicherweise in eine Ereignisweiterleitungs-Eigenschaft verschoben wird.

Diese Bewertung ist nur erforderlich, wenn Sie erwägen, ein clientseitiges Anbieter-Tag zu entfernen und es durch die serverseitige Datenverteilung in einer Ereignisweiterleitungs-Eigenschaft zu ersetzen. In diesem Artikel wird davon ausgegangen, dass Sie mit den Grundlagen von Datenerfassung, und Ereignisweiterleitung.

Browser-Anbieter ändern die Behandlung von Drittanbieter-Cookies. Anbieter und Technologien für Werbung und Marketing erfordern häufig die Verwendung vieler Client-seitiger Tags. Diese Herausforderungen sind nur zwei überzeugende Gründe dafür, dass unsere Kunden die serverseitige Datenverteilung hinzufügen.

Anwendungsbeispiele und Daten use-cases-data

Der erste Schritt besteht darin, die Anwendungsfälle zu definieren, die mit dem clientseitigen Anbieter-Tag implementiert wurden. Betrachten Sie beispielsweise das Facebook-Pixel (Meta). Verschieben Sie ihn von unserer Website in die Meta Conversions-API mit der Ereignisweiterleitungs-Erweiterung bedeutet, dass die spezifischen Anwendungsfälle zuerst dokumentiert werden.

Für den aktuellen clientseitigen Anbietercode:

Es ist hilfreich, eine Liste, Tabelle, ein Diagramm oder einen anderen Datensatz der Daten und Ereignisabfolge zu erstellen, um diese Auswertung zu dokumentieren - auch wenn sie nur für Ihre eigene Verwendung bestimmt ist. Stellen Sie sicher, dass Beschriftungen für Datenquellen enthalten sind - woher kommen sie? Ziele - wohin geht es? Und Transformationen - was passiert damit zwischen Quelle und Ziel?

In unserem Beispiel verfolgen wir Konversionen mit dem Facebook-Pixel, wenn Besucher nach Ansicht einer Facebook-Anzeige mit unserer Site interagieren. Sie können auch mit unserer Site interagieren, nachdem sie verwandte Anzeigen auf einer anderen sozialen Plattform angesehen haben. Um diese Konversionen in den Facebook-Werbe-Tools und -Berichten anzuzeigen, müssen die erforderlichen Daten an Facebook übermittelt werden. Diese Daten können Konversionsereignisse wie Downloads, Registrierungen, "Gefällt mir"-Klicks oder Käufe enthalten.

Daten data

Was geschieht mit den Daten für unseren Anwendungsfall, wenn das vorhandene clientseitige Tag auf unserer Site ausgeführt oder ausgeführt wird? Können wir die benötigten Daten im Client ohne das Anbieter-Tag erfassen, damit wir sie an die Ereignisweiterleitung senden können? Bei Verwendung von tags oder anderen Tag-Management-Systemen stehen die meisten Besucherinteraktionsdaten für die Erfassung und Verteilung zur Verfügung. Aber sind die Daten, die wir für unseren Anwendungsfall benötigen, verfügbar, wenn wir ihn benötigen, wo wir ihn brauchen und in dem Format, das wir ihn benötigen - ohne das Client-seitige Anbieter-Tag? Im Folgenden finden Sie einige weitere Datenfragen, die beachtet werden müssen:

Die meisten clientseitigen Anbieter-Tags benötigen für keinen bestimmten Anwendungsfall viele Datenpunkte. Es ist jedoch hilfreich, die Anwendungsfälle und erforderlichen Daten bei diesen Auswertungen zu beachten.

Anbieter-APIs vendor-apis

Jetzt kennen wir die spezifischen Anwendungsfälle, die implementiert werden müssen, die erforderlichen Daten und die Reihenfolge der Ereignisse von der Quelle bis zum Ziel. Um festzustellen, ob der Anwendungsfall für die Ereignisweiterleitung geeignet ist, können wir jetzt die Details der Anbieter-API untersuchen.

APIs untersuchen investigate-apis

Im Folgenden finden Sie einige Schritte, die wir zur Untersuchung von Anbieter-API-Endpunkten durchführen können.

Verfügt der Anbieter über APIs für die Übertragung von Ereignisdaten von Server zu Server? Suchen Sie zunächst die Anforderungen für diese spezifischen API-Endpunkte:

Mit anderen Worten:

Das -Tag ist wahrscheinlich ein guter Kandidat, um in einer Ereignisweiterleitungseigenschaft vom Client zu unseren Servern zu wechseln, wenn wir auf diese Fragen mit Ja antworten können.

Wenn der Anbieter nicht über die API-Endpunkte verfügt, die unsere Anwendungsfälle unterstützen, ist dieses Anbieter-Tag offensichtlich kein guter Kandidat für die Verwendung der Ereignisweiterleitung anstelle des clientseitigen Anbieter-Tags.

Was passiert, wenn sie über APIs verfügen, aber bei jedem API-Aufruf auch eine Unique Visitor- oder Benutzer-ID benötigen? Wie können wir auf diese ID zugreifen, wenn der clientseitige Code (Tag) des Anbieters nicht auf der Site ausgeführt wird?

Einige Anbieter ändern ihre Systeme für die neue Welt ohne Drittanbieter-Cookies. Zu diesen Änderungen gehört die Verwendung alternativer eindeutiger Kennungen, z. B. einer UUID oder andere kundengenerierte ID. Wenn der Anbieter eine kundengenerierte ID zulässt, können wir sie entweder vom Client mit dem Web- oder Mobile-SDK an Platform Edge Network senden oder möglicherweise von einem API-Aufruf in der Ereignisweiterleitung abrufen. Wenn wir Daten an diesen Anbieter in einer Ereignisweiterleitungsregel senden, fügen wir diese Kennung einfach nach Bedarf hinzu.

Wenn der Anbieter Daten benötigt (z. B. eine herstellerspezifische eindeutige ID), die nur von seinem eigenen clientseitigen Tag generiert oder aufgerufen werden können, ist dieses Anbieter-Tag wahrscheinlich kein guter Kandidat für die Verschiebung. Es wird davon abgeraten, einen Client-seitigen Tag umzukehren, um die Datenerfassung zur Ereignisweiterleitung ohne die entsprechenden APIs zu verschieben.

Die Adobe Experience Platform Cloud Connector -Erweiterung kann bei Anbietern, die über die entsprechenden APIs für die Übertragung von Server-zu-Server-Ereignisdaten verfügen, nach Bedarf HTTP-Anfragen stellen. Auch wenn herstellerspezifische Erweiterungen gut zu haben sind und sich derzeit weitere Erweiterungen in der aktiven Entwicklung befinden, können wir heute mit der Cloud Connector-Erweiterung Ereignisweiterleitungsregeln implementieren, ohne auf zusätzliche Erweiterungen von Anbietern warten zu müssen.

Tools tools

Die Untersuchung und Prüfung von Anbieter-API-Endpunkten ist mit Tools wie Postmanoder Texteditorerweiterungen wie Visual Studio Code Thunder Clientoder HTTP-Client.

Nächste Schritte next-steps

Dieser Artikel enthält eine Reihe von Schritten zum Auswerten eines clientseitigen Tags eines Anbieters und zum möglichen Verschieben dieses Tags serverseitig in eine Ereignisweiterleitungseigenschaft. Weitere Informationen zu verwandten Themen finden Sie unter diesen Links: