Tray ist ein Anbieter von E-Commerce-Content-Management-Systemen (CMS) mit über 20 Jahren Erfahrung im brasilianischen Einzelhandel. Händler betreiben Onlineshops auf der Tray's-Infrastruktur, die auch Dienste und Integrationen zur Verwaltung der Geschäftslogistik, Zahlungen, Angebote und Berichte bietet.
Tray ist Mitglied der Gruppe LWSA und eine treibende Kraft im E-Commerce-Sektor. Tray wird von über 180.000 Kunden genutzt, die im ersten Quartal 2024 zusammen einen GMV von über 3 Milliarden$erzielt haben.
Abhängigkeit von Drittanbieter-Cookies
In der technischen Architektur von Tray's werden Drittanbieter-Cookies verwendet, um Händlerwebsites Drittanbieterfunktionen zur Verfügung zu stellen, insbesondere für das Backoffice-Verwaltungspanel des Händlers, das für die Store-Verwaltung verwendet wird. Diese Cookies sind für das Rendern von Inhalten erforderlich, die von Drittanbieteranwendungen bereitgestellt werden, die auf anderen Domains als der des Händlers gehostet werden. Tray's Recherchen haben ergeben, dass geplante Änderungen an der Verarbeitung von Drittanbieter-Cookies durch Browser diese Funktion möglicherweise beeinträchtigen könnten. Da Tray eine kritische Infrastruktur für viele Onlinehändler darstellt, ist es wichtig, dass der Betrieb wie gewohnt weiterlaufen kann – auch wenn es große Änderungen an der Verarbeitung von 3PCs in Chrome und anderen Browsern gibt.
In dieser Fallstudie wird beschrieben, wie Tray's potenzielle Unterbrechungen erkannt, potenzielle Lösungen bewertet und eine erfolgreiche Lösung implementiert hat, um sicherzustellen, dass seine Websites für Änderungen an 3PCs bereit sind.
Technische Architektur
Mikrodienste
Tray hostet alle Storefront- und Back-Office-Anwendungen auf seiner Domain tray.com.br. Händler können diese Anwendungen über einen CNAME von ihrer eigenen benutzerdefinierten Domain aus bereitstellen. Bei dieser Konfiguration sehen Käufer nur die Domain des Geschäfts, z. B. beispiel.händler. Tray nutzt eine Mikrodienstarchitektur, um Funktionen bereitzustellen. Bei diesem Ansatz werden unabhängige, in sich geschlossene Anwendungen verwendet, die sich jeweils auf eine bestimmte Funktion konzentrieren. Diese Mikrodienste werden dann basierend auf ihren funktionalen Fähigkeiten in Bereiche gruppiert:
- Shop:Umfasst Anwendungen, die für Funktionen der Verkäuferseite wie Produktanzeige, Suche und Themenverwaltung verantwortlich sind.
- Kaufvorgang: Verwaltet den Einkaufswagen, den Bezahlvorgang und die Kundeninteraktionen während des Kaufprozesses.
- Geschäftsverwaltung:Bietet Back-Office-Anwendungen für Aufgaben wie Verwaltung, Berichterstellung und Datenimport.
- Integrationen:Ermöglicht Verbindungen zu externen Plattformen, um Marktplatz-Einträge zu erstellen, die Logistik zu verwalten und mehr.
Backoffice-Anwendung
Das Backoffice ist eine zentrale Anwendung im Store-Management und dient als zentraler Verwaltungsbereich für den virtuellen Shop eines Verkäufers auf Tray. Über dieses Steuerfeld können Verkäufer Folgendes tun:
- Produkte registrieren
- Versand- und Zahlungsmethoden konfigurieren
- Werbeaktionen erstellen
- Livestreams verwalten
- Bestellablauf im Blick behalten
- Verkaufsberichte im Blick behalten
Da das Backoffice viele Microservices – einige von Tray und einige von Drittanbietern betrieben – in einer einzigen Benutzeroberfläche zusammenführt, ist es besonders anfällig für Unterbrechungen, die sich aus Änderungen bei der Verarbeitung von Drittanbieter-Cookies ergeben.
CNAMEs für die Händleranpassung
Tray nutzt CNAME-Einträge, um Shops nahtlos zu integrieren.
Beim Einrichten eines neuen Geschäfts können Händler CNAMEs einrichten, um Anfragen an Anwendungen weiterzuleiten, die auf der Tray's-Domain tray.com.br gehostet werden. Wenn ein Kunde also die Website eines Händlers besucht (z. B. example.com), wird er über einen CNAME-Eintrag an die Tray's-Domain weitergeleitet, während die URL des Händlers in der Adressleiste erhalten bleibt. So wird eine reibungslose Nutzererfahrung geschaffen, bei der Inhalte direkt von der Website des Händlers ausgeliefert werden.
CNAMEs
CNAME-Einträge funktionieren ähnlich wie die Anrufweiterleitung auf einem Smartphone. Angenommen, Sie rufen einen Freund unter der Nummer 555-0199 an, er hebt aber nicht ab. Der Anruf wird möglicherweise an die Voicemail einer anderen Nummer weitergeleitet, z. B. 555-0100. Sie als Anrufer bemerken diese Weiterleitung jedoch nicht. Das Smartphone stellt eine nahtlose Verbindung her und in der Ansage der Voicemail wird weiterhin die ursprüngliche Nummer Ihres Freundes (555-0199) angezeigt.
CNAMEs funktionieren für Websites auf dieselbe Weise. Wenn ein Nutzer die Website eines Händlers besucht (z. B. example.com), wird seine Anfrage möglicherweise über einen CNAME-Eintrag im Hintergrund an einen anderen Server wie assets.example.com weitergeleitet. Aus Sicht des Nutzers und des Browsers geschieht jedoch alles auf example.com. In der Adressleiste wird die URL des Händlers angezeigt und der Nutzer interagiert mit der Website, als würden die Inhalte direkt von dieser Domain stammen.
Potenzielle Unterbrechungen bewerten
Tray's Bei der Analyse der geplanten Änderungen an der 3PC-Verarbeitung wurden Unterbrechungen in der Backoffice-Anwendung festgestellt. Wenn 3PCs blockiert wurden, traten beim Laden von Seiten aus verschiedenen Domains innerhalb von Iframes, die in Backend-Seiten eingebettet waren, Probleme auf. Dies galt sowohl für interne Domains, die zu den eigenen Diensten des Unternehmens gehörten, als auch für externe Partner, die Anwendungen entwickeln, die über die API in Tray eingebunden sind.
Angenommen, auf einer Seite auf backoffice.merchant.example sind Inhalte eingebettet, die von tray.com.br und anderen Drittanbietern gehostet werden.
Browser würden diese eingebetteten Inhalte aufgrund der Domaindifferenz als Drittanbieter behandeln und sie möglicherweise aufgrund von Einschränkungen für Drittanbieter einschränken.
Diese Konfiguration kann zu mehreren Problemen führen:
- Abgebrochene Sitzungen:Blockierte Drittanbieter-Cookies können dazu führen, dass betroffene Sitzungen abgebrochen werden. Das kann die Nutzererfahrung beeinträchtigen, da sich Nutzer mehrmals anmelden müssen, oder zu Störungen oder Inkonsistenzen auf Backoffice-Seiten aufgrund von nicht funktionierenden Iframes führen.
- Integrationsprobleme: Partneranwendungen und interne Dienste, die über die API mit dem Tray's-Backend verbunden sind, können aufgrund von Einschränkungen für Drittanbieter ähnliche Probleme verursachen.
Das folgende Diagramm veranschaulicht dieses Szenario:
- Ein Nutzer greift auf die Backoffice-Anwendung zu, die auf
merchant.examplegehostet wird. - Eingebettete Anwendungen befinden sich auf verschiedenen Domains, einige auf
tray.com.br, die zu Tray gehört, andere auf Domains von Drittanbietern (third-party.example). - Diese Domainabweichung löst 3PC-Einschränkungen aus, was möglicherweise zu Problemen mit den eingebetteten Anwendungen führt.
Abhängigkeiten von Drittanbieter-Cookies und Lösungen analysieren
Wichtige User Journeys testen
Die Tray's-Tests und ‑Analysen zielten darauf ab, die Websiteleistung und die Nutzerfreundlichkeit zu verbessern, wobei der Schwerpunkt auf Integrationen von Drittanbietern und der Vorbereitung auf eine Zukunft gelegt wurde, in der viele Nutzer ohne 3PCs surfen.
Tray hat das Privacy Sandbox Analysis Tool (PSAT) und die Chrome-Entwicklertools verwendet, um wichtige Nutzerflüsse für Kunden und Händler zu analysieren. Dabei wurde das Laden von Seiten in iFrames getestet, geprüft, ob Nutzersitzungen gültig blieben, und sichergestellt, dass Drittanbieteranwendungen weiterhin wie erwartet funktionierten. Die Tests umfassten verschiedene Nutzerrollen, Geräte und Browser (einschließlich Chrome, Firefox und Safari), um potenzielle browserübergreifende Kompatibilitätsprobleme zu identifizieren. Tray hat PSAT und die Chrome-Entwicklertools verwendet, um Cookies zu kategorisieren und ihre Auswirkungen auf die Nutzerfreundlichkeit zu bewerten.
Diese Analyse war ein wichtiger Schritt, um eine reibungslose und einheitliche Nutzererfahrung zu gewährleisten und sich auf eine Zukunft vorzubereiten, in der Drittanbieter-Cookies möglicherweise eingeschränkt oder nicht verfügbar sind.
Privacy Sandbox-Lösungen analysieren
Storage Access API
Die Storage Access API (SAA) kann zwar potenziell Tray's-Unterbrechungen beheben und wird von allen gängigen Browsern unterstützt, war aber aus zwei Hauptgründen nicht die beste Lösung für das Unternehmen:
- Die eingebetteten Inhalte mussten nur auf Cookies an der Quelle zugreifen, an der sie eingebettet wurden, nicht auf dieselben Cookies auf mehreren Websites.
- Die Browseraufforderungen, die mit der SAA verknüpft waren, waren nicht ideal, insbesondere da keine Cookies verwendet wurden, um Nutzer über Websites hinweg zu erfassen.
CHIPS
CHIPS bot eine leistungsstarke Lösung mit einer hervorragenden Nutzerfreundlichkeit für websiteübergreifende Einbettungen. Das Attribut Partitioned war einfach zu implementieren und hatte keine wahrnehmbaren Auswirkungen auf die Nutzerinteraktion in Chrome. CHIPS wurde von anderen wichtigen Browsern nicht unterstützt, als Tray Änderungen an seinem Dienst vornahm. Daher entschied sich das Unternehmen, seine eigenen eingebetteten Inhalte auf die Website der Anwendung der obersten Ebene zu verschieben, um eine einheitliche Browsererfahrung zu ermöglichen. Eingebettete Inhalte von Drittanbietern basieren auf CHIPS in Chrome und öffnen in anderen Browsern ein neues Fenster (Eigentümerkontext). Seit der Tray's ursprünglichen Implementierung hat Firefox jedoch bestätigt, dass CHIPS bald eingeführt wird, und Safari hat damit begonnen, Unterstützung für das Attribut „Partitioned“ hinzuzufügen, beginnend mit der Technologievorschau.
Wir fanden CHIPS eine elegante Lösung und freuen uns, dass sie in mehreren Browsern eingesetzt wird. Wir haben uns entschieden, die CHIPS-Lösung beizubehalten und die Migration zu Websites mit selbst erhobenen Daten voranzutreiben, damit wir alle Browser unterstützen können, auch bevor sie CHIPS einführen.
– Takashi Tanaka, CTO von Tray
Browserkompatibilität, W3C und Standards
Chrome spielt in der Standardszene eine zentrale Rolle. Die aktive Teilnahme an W3C-Arbeitsgruppen und Community-Gruppen wie der PrivacyCG ist entscheidend, um das gesamte Browser-Ökosystem dazu zu bewegen, neue Webtechnologien zu übernehmen.
Die Privacy Sandbox arbeitet mit dem Web-Ökosystem zusammen, um APIs wie CHIPS basierend auf Feedback und Engagement der Branche kontinuierlich weiterzuentwickeln. Dieser transparente und standardsorientierte Ansatz hat dazu beigetragen, die Einführung von CHIPS in anderen großen Browsern voranzutreiben.
Dauerhafte Lösung für Drittanbieter-Cookie-Abhängigkeiten
Tray unterstützt Händler und ihre Kunden auf allen Arten von Geräten und in allen Browsern. Ein rein CHIPS-basierter Ansatz wäre vorzuziehen gewesen, aber es wurden auch zusätzliche Änderungen vorgenommen, um andere Browser zu unterstützen, die CHIPS zu diesem Zeitpunkt nicht unterstützten.
Tray's Der Ansatz zur Behebung von Unterbrechungen, die durch nicht verfügbare 3PCs verursacht werden, umfasste zwei Hauptstrategien.
1. Interne Anwendungen
Vollständig betriebene Tray-Mikrodienste wie Live Shop, Dropshipping und Rechnungsaussteller wurden so aktualisiert, dass die Quelle der eingebetteten Inhalte den vom Händler eingerichteten CNAME übernimmt. Die eingebetteten Inhalte wurden einfach so aktualisiert, dass sie von der Seite stammen, auf der sie eingebettet sind. So konnten Unterbrechungen aufgrund von Änderungen an Drittanbieter-Cookies vermieden werden.
2. Drittanbieteranwendungen
Für Drittanbieteranwendungen, auf die über das Backoffice zugegriffen wird, hat Tray einen dynamischeren Ansatz implementiert. So funktionierts:
- Implementierung des partitionierten Attributs:Die Implementierung des
Partitioned-Cookie-Attributs wurde für vertrauenswürdige Anbieter beibehalten. So können Drittanbieter-Anwendungen weiterhin effektiv Cookies in Browsern setzen, die CHIPS unterstützen. - Wenn Drittanbieter-Cookies blockiert sind:Wenn der Browser des Nutzers Drittanbieter-Cookies blockiert, wird die Drittanbieter-Anwendung in einem neuen Fenster geöffnet. So werden Probleme beim Öffnen vermieden und der Betrieb wird auch bei 3PC-Einschränkungen aufrechterhalten.
- Wenn Drittanbieter-Cookies erlaubt sind:Wenn der Browser des Nutzers Drittanbieter-Cookies zulässt, wird die Anwendung wie bisher in iFrames geöffnet.
Lösung visualisieren
Die folgende Abbildung veranschaulicht die Lösung. Da die Hauptdomain des Shops (merchant.example) übernommen wird, stammen alle eingebetteten Anwendungen aus derselben Quelle. Dadurch sind alle Widgets füreinander selbst erhobene Daten, d. h. Einschränkungen für Drittanbieter-Daten spielen keine Rolle. Da alle diese Frames zu eigenen Cookies werden, gelten für sie dieselben Datenschutzgrundsätze wie für andere eigene Cookies: Sie sind nur im Kontext eigener Cookies zugänglich und beschränken das Potenzial für websiteübergreifendes Tracking.
Drittanbieterdienste, die nicht zu Tray gehören, verwenden das Partitioned-Attribut, um CHIPS-Cookies zu setzen. Das bedeutet, dass sie auch nur im Kontext zugänglich sind, in dem sie festgelegt wurden, und das Potenzial für websiteübergreifendes Tracking wird eingeschränkt.
Fazit
- Es gibt keine allgemeingültige Lösung für den Datenschutz im Web. Es gibt viele Möglichkeiten, eine reibungslose Nutzererfahrung zu ermöglichen und gleichzeitig den Datenschutz zu wahren.
- Wenn Sie Ressourcen in derselben Top-Level-Domain zusammenführen, können Cookies auch bei Einschränkungen für Drittanbieter-Cookies funktionieren.
- CHIPS ist möglicherweise eine einfachere Lösung als die Migration aller Ressourcen zur selben Website der obersten Ebene.
- Tray's-Lösung ist zukunftsfähig und funktioniert plattformübergreifend. Da weitere Browser CHIPS unterstützen, kann es als zuverlässige browserübergreifende Lösung für Szenarien wie Tray's betrachtet werden.