Cookieless Attribution erklärt: Was im Jahr 2026 noch funktioniert

Der Marketing-Attributions-Stack, den die meisten Teams zwischen 2012 und 2019 aufgebaut haben, basierte auf zwei Dingen: einem Drittanbieter-Cookie, das von der Anzeigenplattform auf der Landingpage gesetzt wurde, und einem Browser-Pixel, das auf der Conversion-Seite ausgelöst und mit diesem Cookie abgeglichen wurde. Beide Hälften dieses Paares sind nun beeinträchtigt. Keine von beiden wird sich erholen.

Dieser Beitrag ist kein Klagelied auf den Cookie. Er ist eine Karte dessen, was im Jahr 2026 tatsächlich funktioniert – welche Attributionspfade überlebt haben, welche als Lösungen vermarktet wurden, ohne tatsächlich welche zu sein, und wie ein funktionierender Stack in der Praxis für Teams aussieht, die bezahlte Akquisition für EU-Traffic betreiben.

TL;DR#

• Apple's ITP 2.3, Firefox Enhanced Tracking Protection und das laufende Chrome third-party cookie phase-out führen zusammen dazu, dass 60–70 % des EU-Webtraffics Drittanbieter-Cookies standardmäßig blockieren oder stark einschränken.
• Zwei Attributionspfade funktionieren weiterhin: Server-seitige Identifikatoren, die über eine Click-ID übergeben werden, und das Setzen von First-Party-Cookies über eine Redirect-Kette, die Ihre Domain kontrolliert.
• Cookieless bedeutet nicht einwilligungsfrei. Die ePrivacy-Richtlinie 2002/58/EG und die GDPR erfordern weiterhin eine Einwilligung für nicht-essenzielle Analysen, unabhängig vom Speichermechanismus.
• Probabilistisches Fingerprint-Stitching ist in der EU kein rechtskonformer Fallback; deterministisches E-Mail-Hash-Matching in Kombination mit einer Server-seitigen Click-ID ist der einzige Ansatz, der sowohl der Genauigkeit als auch der regulatorischen Prüfung standhält.

Was sich geändert hat: Ein kurzer Zeitstrahl#

Safari begann 2017 mit ITP 1.0, Drittanbieter-Cookies einzuschränken. Die Beschränkungen eskalierten schnell. ITP 2.3, veröffentlicht im September 2019, begrenzte die Lebensdauer von skriptgesteuerten First-Party-Cookies auf sieben Tage und auf vierundzwanzig Stunden, wenn die Empfehlungskette einen bekannten seitenübergreifenden Tracker enthielt. Diese Änderung allein brach die Standard-Übergabe von Click-ID zu Cookie, auf die sich die meisten Attributionsanbieter verließen.

Firefox' Enhanced Tracking Protection lieferte 2022 Total Cookie Protection an alle Nutzer aus, wodurch jedes Drittanbieter-Cookie nach der Top-Level-Seite partitioniert wurde. Ein von pixel.example.com auf Ihrer Checkout-Seite und der Checkout-Seite Ihres Konkurrenten gesetztes Cookie sind nun zwei völlig separate Cookies – die seitenübergreifende Korrelation ist konstruktionsbedingt verschwunden.

Der Zeitplan von Chrome hat sich seit der Ankündigung durch Google im Jahr 2019 mehrmals verschoben. Der aktuelle Stand, dokumentiert auf der Privacy Sandbox Website (abgerufen am 12.05.2026), sieht vor, dass die Deaktivierung für eine Untergruppe von Nutzern voranschreitet, während der vollständige Rollout noch im Gange ist. Unabhängig vom endgültigen Datum für Chrome ist das Bild in der EU bereits geklärt: Safari und Firefox machen zusammen den Großteil des mobilen und datenschutzbewussten Desktop-Traffics in EU-Märkten aus. Attributionsstrategien, die Drittanbieter-Cookies erfordern, sind für einen großen Teil Ihres europäischen Publikums bereits hinfällig.

Der kombinierte Effekt, gemessen über typische EU-Performance-Marketing-Accounts: Die browserseitige Pixel-Attribution unterschätzt Conversions um 25–45 %, abhängig vom Traffic-Mix, wobei iOS-lastige Verticals (Mode, Beauty, Apps, Abonnementdienste) am oberen Ende dieses Bereichs liegen.

Die zwei überlebenden Attributionspfade#

Pfad 1: Server-seitige Identifikatoren#

Der Kernmechanismus ist einfach. Wenn ein Nutzer auf Ihre Anzeige klickt, hängt die Anzeigenplattform eine Click-ID an die Landing-URL an – fbclid für Meta, gclid für Google und so weiter. Dieser Identifikator existiert in der URL, nicht in einem Cookie, sodass ITP und Cookie-Partitionierung ihn nicht berühren.

Ihre Landingpage liest die Click-ID aus der URL und schreibt sie in ein First-Party-Cookie auf Ihrer eigenen Domain oder leitet sie an Ihren Warenkorb und schließlich in den Bestelldatensatz weiter. Wenn der Nutzer konvertiert, liest Ihr Backend die Click-ID aus der Bestellung und sendet die Conversion Server-zu-Server an die Conversion-API der Anzeigenplattform – Meta's Conversions API, GA4 Measurement Protocol, den Server-Side-Events-Endpunkt von Mixpanel.

Dieser Pfad funktioniert, weil er nie mit Drittanbieter-Cookies in Berührung kommt. Die Click-ID befindet sich im Moment der Landung im URL-Query-String. Ihr First-Party-Cookie auf Ihrer eigenen Domain wird von ITP nicht in der gleichen Weise eingeschränkt wie Drittanbieter-Cookies (obwohl es der 7-Tage-Grenze für skriptgesteuerte Cookies unterliegt, wenn die Empfehlungskette verdächtig ist – mehr dazu unten). Das Conversion-Event fließt Server-zu-Server, völlig außerhalb des Browsers.

Die Schwachstellen sind real. Wenn der Nutzer zwischen Landung und Conversion Cookies löscht, ist die Click-ID weg. Wenn die Conversion auf einem anderen Gerät stattfindet, gibt es keine geräteübergreifende Verknüpfung, es sei denn, Sie haben einen angemeldeten Nutzer mit einer bekannten E-Mail-Adresse. Und iOS 17 führte Link Tracking Protection im privaten Surfen und in Mail ein, wodurch bekannte Click-ID-Parameter aus URLs entfernt werden – fbclid, gclid, msclkid stehen auf der Streichliste. Ein Nutzer, der über die Mail-App mit aktivierter Link Tracking Protection kommt, überträgt die Click-ID überhaupt nicht auf Ihre Website.

Pfad 2: First-Party-Redirect-Kette#

Der zweite überlebende Pfad nutzt einen Redirect, den Sie kontrollieren, als Attributionsfläche. Anstelle der Click-ID der Anzeigenplattform generieren Sie Ihren eigenen persistenten Identifikator im Moment des Redirects auf Ihrer eigenen Domain.

Wenn ein Nutzer auf einen Link auf Ihrer Domain klickt – sei es ein Kurzlink, ein Kampagnen-Landing-Redirect oder ein Marken-Deep-Link – läuft der Redirect-Handler auf Ihrem Edge, bevor die Datenschutzbeschränkungen des Browsers greifen. Er kann:

1. Ein First-Party-Cookie mit einer servergenerierten Click-ID auf Ihrer Domain setzen.
2. Die Click-ID als URL-Parameter an die Ziel-URL anhängen.
3. Das Klick-Event serverseitig mit dem vollständigen technischen Kontext (IP, User-Agent, Referrer, Zeitstempel) im Moment des Klicks protokollieren, statt erst beim Laden der Seite.

Da dies Ihre Domain und Ihr serverseitiges Cookie ist, liegt es außerhalb der Beschränkungen für Drittanbieter-Cookies, auf die ITP abzielt. Das Cookie wird von Ihrem Server über einen Set-Cookie-Response-Header bei der Redirect-Antwort gesetzt – serverseitig gesetzte Cookies unterliegen nicht der 7-Tage-ITP-Grenze, die für document.cookie-Schreibvorgänge aus JavaScript gilt.

Dies ist die Attributionsfläche, die ein URL-Shortener bietet, ein Browser-Pixel jedoch nicht. Der Redirect wird auf der Domain des Shorteners aufgelöst. Wenn diese Domain Ihre eigene Markendomain ist, ist Ihre Click-ID First-Party, serverseitig gesetzt und architektonisch positioniert, bevor eine browserseitige Datenschutzbeschränkung greift.

Wie ein Kurzlink zur Attributionsfläche wird#

Der Redirect-Flow funktioniert wie folgt: Die Ziel-URL Ihrer Anzeige ist ein Marken-Kurzlink – zum Beispiel go.acme.example/summer-sale. Der Nutzer klickt. Die Redirect-Anfrage erreicht den Edge-Handler von Elido, der:

• Die Ziel-URL nachschlägt.
• Einen elido_click-Identifikator generiert und das Klick-Event serverseitig protokolliert.
• Ein First-Party Set-Cookie: elido_click=<id>; Domain=go.acme.example; SameSite=Lax; Secure; Max-Age=604800 auf die Redirect-Antwort setzt.
• ?elido_click=<id> an die Ziel-URL anhängt, bevor er weiterleitet.

Die Zielseite erhält die Click-ID im Query-String. Ihr Tag-Manager oder Theme-Code liest sie aus und speichert sie im Warenkorb oder Bestelldatensatz. Wenn die Conversion stattfindet, senden Sie einen POST an POST /v1/conversions mit der Click-ID und den Bestelldetails – Elido kümmert sich um das SHA-256-Hashing der Kundenidentifikatoren und den serverseitigen Fan-out an Meta CAPI, GA4 Measurement Protocol und Mixpanel.

Die Click-ID befand sich nie in einem Drittanbieter-Cookie. Sie war serverseitig gesetzt, First-Party und wurde protokolliert, bevor die Datenschutzschicht des Browsers eingreifen konnte. Für die vollständige Mechanik des serverseitigen Weiterleitungsschritts behandelt Server-seitiges Conversion-Tracking über Kurzlinks die Deduplizierung, Hashing-Anforderungen und Retry-Semantik im Detail.

Für die allgemeinere Frage, wie ITP die Klick-Attribution spezifisch beeinträchtigt und was die Kurzlink-Redirect-Kette dagegen unternimmt, ist Klick-Attribution nach Safari ITP der operative Begleiter zu diesem Beitrag.

Identity Stitching: Was funktioniert und was nicht#

Serverseitige Click-IDs lösen das Attributionsproblem für Nutzer, die auf einen Link klicken und in derselben Browser-Sitzung auf demselben Gerät konvertieren, ohne Cookies zu löschen und ohne dass Link Tracking Protection den Parameter entfernt. Das deckt immer noch die Mehrheit der E-Commerce-Conversions ab. Aber es deckt nicht alles ab, und die Ansätze, die Teams verwenden, um die verbleibende Lücke zu schließen, variieren erheblich sowohl in der Genauigkeit als auch im rechtlichen Risiko.

Deterministisches Matching funktioniert. Wenn der Nutzer angemeldet ist oder an irgendeinem Punkt im Funnel seine E-Mail-Adresse angibt (E-Mail-Erfassung, Newsletter-Anmeldung, Checkout), können Sie diese E-Mail-Adresse mit SHA-256 hashen und in das Conversion-Event aufnehmen. Meta CAPI, GA4 und Mixpanel akzeptieren alle die gehashte E-Mail als Matching-Signal neben oder anstelle einer Click-ID. Die Match-Rate für Traffic mit bekannter E-Mail ist hoch – Meta berichtet intern über Match-Raten von über 90 %, wenn eine normalisierte, gehashte E-Mail vorhanden ist. Dies ist der primäre Stitching-Mechanismus, der die Cookie-Deprecierung unbeschadet übersteht.

Das Deduplizierungs-Pairing ist hier entscheidend. Jedes Conversion-Event benötigt eine event_id (für Meta) oder transaction_id (für GA4), die zwischen dem browserseitigen Pixel und dem serverseitigen Sendevorgang identisch ist. Ohne diese werden beide Ereignisse erfasst und die Conversion doppelt gezählt. Die Bestell-ID ist der Standard-Dedup-Key für Kaufereignisse.

Probabilistisches Fingerprinting funktioniert nicht – und ist in der EU nicht legal. Browser-Fingerprinting setzt einen eindeutigen Identifikator aus der Kombination von Bildschirmauflösung, installierten Schriftarten, Zeitzone, User-Agent, Canvas-Rendering-Fingerprint und ähnlichen Signalen zusammen. Der Identifikator ist probabilistisch – er weist eine hohe Übereinstimmungswahrscheinlichkeit zwischen zwei Ereignissen ohne gemeinsames Cookie oder Login zu. Einige Attributionsanbieter bieten dies als „cookieless measurement“-Lösung an.

In der EU hat dieser Ansatz ein spezifisches rechtliches Problem. Die ePrivacy-Richtlinie 2002/58/EG, Artikel 5(3), erfordert eine Einwilligung für den Zugriff auf oder die Speicherung von Informationen auf der Endeinrichtung eines Nutzers. Die Position des EDPB, die in mehreren Entscheidungen von Aufsichtsbehörden seit 2022 wiederholt wurde, ist, dass Fingerprinting in den Anwendungsbereich von Artikel 5(3) fällt, unabhängig davon, ob der Identifikator technisch ein „Cookie“ ist. Die österreichische DSB, die französische CNIL und der italienische Garante haben jeweils Durchsetzungsmaßnahmen gegen Fingerprinting ohne Einwilligung erlassen. Die Behauptung „Wir verwenden keine Cookies, wir verwenden Fingerprinting“ ist kein Compliance-Argument; es ist das Argument, das zu einer genaueren Prüfung einlädt.

Selbst abgesehen vom rechtlichen Risiko nimmt die Genauigkeit des probabilistischen Fingerprintings ab, wenn die Browser-Entropie sinkt. Moderne datenschutzorientierte Browser senken die Entropie aktiv, indem sie die Canvas-Ausgabe normalisieren und die Auflösung von Timing-APIs begrenzen. Die Signalqualität sinkt genau in der Bevölkerung – datenschutzbewusst, iOS-lastig –, in der Sie die genaueste Messung am dringendsten benötigen.

Geräteübergreifendes Stitching via CRM ist die verbleibende Lücke. Für Nutzer, die auf einem anderen Gerät konvertieren, als sie geklickt haben, ist deterministisches E-Mail-Matching der einzige Ansatz, der funktioniert. Wenn der Nutzer auf beiden Geräten angemeldet ist, ist die Nutzer-ID das Bindeglied. Wenn er nicht angemeldet ist, können die Click-ID auf Gerät A und die Conversion auf Gerät B nicht miteinander verbunden werden, ohne dass der Nutzer freiwillig einen Identifikator (E-Mail, Telefon) angibt, den Sie hashen und abgleichen können. Diese Lücke kann serverseitig nicht geschlossen werden. Es ist eine reale Attributionsgrenze in der Cookieless-Welt.

Die Compliance-Ebene#

Die Formulierung „Cookieless Attribution“ kann Menschen zu der Annahme verleiten, dass keine Einwilligung erforderlich ist, weil kein Cookie gesetzt wird. Das ist nicht das, was das Gesetz sagt.

Die ePrivacy-Richtlinie 2002/58/EG, Artikel 5(3), gilt für jede Speicherung von oder jeden Zugriff auf Informationen auf der Endeinrichtung eines Nutzers – nicht nur für Cookies. Ein First-Party-Cookie, das für Analysezwecke gesetzt wird, erfordert dieselbe Einwilligung wie ein Drittanbieter-Cookie, das für Trackingzwecke gesetzt wird, wenn dieses Cookie nicht essenziell ist. Das oben beschriebene serverseitige Click-ID-Cookie ist analyse-nah; es kann eine Einwilligung erfordern oder auch nicht, abhängig von der Bewertung des Zwecks durch Ihren Verantwortlichen und der geltenden nationalen Umsetzung der Richtlinie.

Was der serverseitige Ansatz bewirkt – und das ist sein eigentlicher Compliance-Vorteil –, ist die Verlagerung der Verarbeitung weg vom Gerät des Nutzers hin zum Server. Das Klick-Event-Log, die Conversion-Event-Weiterleitung, das Identity-Stitch: Diese finden in Ihrem Backend und dem Backend von Elido statt, nicht in einem Browser-Skript. Das bedeutet, dass Werbeblocker sie nicht abfangen, Browser-Datenschutzfunktionen sie nicht partitionieren und die Datenminimierung von Ihnen kontrolliert werden kann, anstatt davon abhängig zu sein, was ein Drittanbieter-Tag zu senden entscheidet.

Die Frage der Rechtsgrundlage nach GDPR ist von der ePrivacy-Frage getrennt. Auch bei der serverseitigen Attribution benötigen Sie eine Rechtsgrundlage nach GDPR Artikel 6 für die Verarbeitung von Klickdaten identifizierbarer EU-Personen. Für Analysen auf Kampagnenebene begründen die meisten Verantwortlichen dies mit berechtigtem Interesse nach Artikel 6(1)(f) nach einer Abwägung der berechtigten Interessen (Legitimate Interest Assessment). Für individuelles Profiling oder Retargeting ist die Grundlage schwieriger. Der Cornerstone GDPR für URL-Shortener deckt die Analyse der Artikel 6, 28 und 30 im Detail ab; die Zusammenfassung hier lautet: Cookieless ≠ einwilligungsfrei, und die Compliance-Ebene verschwindet nicht, nur weil sich der Speichermechanismus geändert hat.

Die Klick-Event-Standardeinstellungen von Elido spiegeln eine Haltung der Datenminimierung wider: IPs werden vor der Speicherung auf /24 (IPv4) gekürzt, vollständige User-Agent-Strings werden geparst und verworfen. Die Daten in voller Auflösung sind pro Workspace verfügbar, wenn Ihr Anwendungsfall dies erfordert, aber die Standardeinstellung ist die konservative. Das ist wichtig für das Gespräch über den Auftragsverarbeitungsvertrag (AVV/DPA) mit Ihren Einkäufern. Mehr zu diesem Gespräch finden Sie unter solutions/marketers, wo die Beschaffungs-Touchpoints für Marketing-Teams behandelt werden.

Was Sie aufgeben#

Die ehrliche Bilanz ist wichtig. Die serverseitige Cookieless-Attribution gewinnt den Großteil des durch die browserseitige Beeinträchtigung verlorenen Signals zurück, aber sie gewinnt nicht alles zurück.

Geräteübergreifende Identität in Echtzeit. Wie oben erwähnt: Wenn ein Nutzer mobil klickt und am Desktop konvertiert, ohne dass ein Login-Ereignis die beiden verknüpft, geht die Attribution verloren. Es gibt keinen rechtskonformen serverseitigen Fix dafür. Die Lücke ist strukturell.

Präzise View-Through-Attribution. View-Through-Attribution – die Gutschrift einer Kampagne für eine Conversion, die auf eine Anzeigenimpression (nicht einen Klick) folgte – erfordert, dass die Anzeigenplattform den Nutzer über beide Ereignisse hinweg abgeglichen hat. Serverseitige Conversion-APIs handhaben klickbasierte Attribution gut; View-Through hängt vom eigenen geräteübergreifenden Graphen der Plattform ab, der sich selbst proportional zum Signalverlust verschlechtert. Erwarten Sie, dass View-Through-Reporting ungenauer und weniger zuverlässig ist als klickbasierte Zahlen.

Lange Lookback-Fenster. Die meisten serverseitigen Conversion-API-Endpunkte erzwingen eine Lookback-Grenze dafür, wie weit in die Vergangenheit ein Klick einer Conversion zugeordnet werden kann. Das Standard-Lookback von Meta CAPI beträgt 7 Tage für Click-Through. Das Measurement Protocol von GA4 hat ein Attributionsfenster, das je nach Kanal variiert. Diese Grenzen sind kürzer als die 28-tägigen oder 90-tägigen Fenster, die einige Teams in der Cookie-basierten Welt verwendeten. Abonnementprodukte und wohlüberlegte Käufe mit langen Recherchezyklen werden mehr Conversions sehen, die aus dem zurechenbaren Fenster fallen.

Last-Click-Dominanz. Ohne einen Multi-Touch-Identity-Graphen standardisiert die serverseitige Attribution auf Last-Click – die jüngste Click-ID in der Kette erhält den Zuschlag. Bei Markenbekanntheitskampagnen, die über einen langen Zeitraum unterstützte Conversions vorantreiben, wird die serverseitige Last-Click-Attribution die Ausgaben im oberen Funnel systematisch unterbewerten. Die Abhilfe ist CRM-Stitching via gehashter E-Mail: Wenn die E-Mail jedes angemeldeten Nutzers bei jeder Conversion vorhanden ist, können Sie eine Multi-Touch-Sequenz für den angemeldeten Teil Ihres Publikums rekonstruieren. Für anonyme Nutzer ist Last-Click die Obergrenze.

Ein praktischer Stack#

Angesichts der oben genannten Einschränkungen ist hier der Attributions-Stack, der für ein Performance-Marketing-Team mit EU-Traffic im Jahr 2026 funktioniert.

Kurzlink-Click-ID als Einstiegspunkt. Alle Anzeigenziele sind Marken-Kurzlinks auf Ihrer Domain. Der Redirect setzt ein serverseitiges First-Party-Cookie und hängt die Click-ID an die Ziel-URL an. Dies gibt Ihnen einen persistenten, serverseitig gesetzten Identifikator, der ITP und Cookie-Partitionierung für die Sitzung übersteht.

Warenkorb- und Bestell-Anbindung. Die Click-ID wird beim Laden der Seite (aus dem URL-Parameter oder dem First-Party-Cookie) in ein Warenkorb-Attribut geschrieben. Bei der Bestellerstellung befindet sich die Click-ID in den benutzerdefinierten Attributen der Bestellung. Dies ist die dauerhafte Übergabe – sobald die Click-ID in der Bestellung ist, läuft sie nicht mehr ab.

Serverseitiges CAPI an Meta. Nach Bezahlung der Bestellung sendet Ihr Backend (oder das Conversion-Forwarding-Feature) einen POST an Meta CAPI mit der Click-ID, der SHA-256-gehashten E-Mail und den fbc/fbp-Identifikatoren aus den First-Party-Cookies. Die event_id ist die Bestell-ID, die mit dem browserseitigen Pixel übereinstimmt. Meta dedupliziert innerhalb des 48-Stunden-Matching-Fensters.

Serverseitiges Measurement Protocol an GA4. Gleichzeitig wird ein GA4-Server-Side-Event mit der transaction_id gleich der Bestell-ID gesendet. Die client_id ist der Wert des GA4 _ga-Cookies, falls verfügbar, sonst die Click-ID als Fallback. GA4 dedupliziert auf der transaction_id innerhalb des Sitzungsfensters.

CRM E-Mail-Hash-Stitch. Für jede Conversion, bei der die Click-ID fehlt (organisch, direkt, Markensuche), ist die gehashte E-Mail-Adresse das Attributionssignal. Dies füllt das Segment der „bekannten Nutzer“ Ihrer Attribution und unterstützt eine grundlegende Multi-Touch-Rekonstruktion für angemeldete Kunden.

Offline-Conversion-Import für langes Lookback. Bei Abonnementprodukten oder B2B-Pipelines, bei denen die Conversion Wochen nach dem Klick erfolgt, ermöglicht der Offline-Conversion-Import über die Batch-API der Plattform (Meta's Conversions API offline events, Google Ads Offline-Conversions) das Senden von Attributionsereignissen über das Echtzeit-Lookback-Fenster hinaus. Der Match-Key ist weiterhin die gehashte E-Mail oder Telefonnummer; das Zeitfenster wird erweitert. Dies löst nicht die anonyme Attribution bei langen Zyklen, schließt aber den Kreis für den Teil Ihres Publikums, der eine E-Mail-Adresse angegeben hat.

Der oben genannte Stack erfordert keine CDP. Er erfordert einen URL-Shortener, der serverseitige Click-IDs generiert und speichert, ein Backend, das die Click-ID bis zur Bestellung durchreicht, und eine Conversion-Forwarding-Schicht, die das Hashing und den API-Fan-out übernimmt. Für die technische Implementierung der Fan-out-Schicht enthält Server-seitiges Conversion-Tracking über Kurzlinks die Payload-Formate, Deduplizierungsmechaniken und Retry-Semantiken. Wo dies in einen vollständigen Kampagnen-UTM-Workflow passt, siehe solutions/marketers.

Die Version dieses Stacks, die nicht funktioniert: Eine, die sich auf den eigenen geräteübergreifenden Graphen der Anzeigenplattform für die Identitätsauflösung verlässt, darauf hofft, dass iOS-Nutzer App Tracking Transparency in einer für Ihre Messung vorteilhaften Weise aktiviert haben, oder probabilistisches Fingerprinting verwendet, um die Lücken zu füllen. Ersteres liegt außerhalb Ihrer Kontrolle. Letzteres ist Wunschdenken. Drittes ist ein Compliance-Risiko in der EU.

Arbeiten Sie mit dem, was hält.