{:de}Die Hoffnung stirbt zuletzt – der Versuch eines Fazits (7/7){:}{:en}Hope is the last to die – the attempt of a conclusion (7/7){:}

• Technik (z.B. AdBlocker)
• Juristisch (DSGVO) 
• Usability (Cross-Device/-Browser)

Nun kommt also ein 4. Problem hinzu: Organisatorisch. Zugegeben es geht eng einher mit dem juristischen Problem, unterscheidet sich aber in einem Punkt wesentlich: Es trifft nun nicht nur Marketing- oder Tracking-Lösungen, sondern quasi jeden Service, jedes Tool, jedes SaaS oder sonstige cloudbasierte Lösung, die von Anbietern aus den USA stammen. Eine schöne Zusammenfassung der Konsequenzen liefert Dr. Ronald Kandelhard in seinem Beitrag “Deine Website ist illegal: Privacy Shield verstößt gegen DSGVO”.

• Office/Kollaboration: G-Suite, Microsoft 365, …
• Projektmanagement: Asana, Trello,
• Messenger: Slack, MS Team,…
• E-Mail: Mailchimp, Sendgrid,…
• CRM: Salesforce, Zoho,…
• Data-Migration: Funnel.io, Segment, Stitch,…
• Monitoring: Sentry, Datadog,…
• u.v.a.

Ob und wann wieder für Rechtssicherheit gesorgt wird, ist aktuell nicht absehbar. Man kann nun entweder versuchen seinen IT-Stack beizubehalten und zu hoffen nicht “erwischt” zu werden, weitere Garantien von den US-Unternehmen einfordern oder man beginnt nach (europäischen) Alternativen zu suchen. In jedem Fall riskiert man entweder einen Verstoß gegen die DSGVO oder es entsteht ein hoher organisatorischer Aufwand.

1. Die “Kopf in den Sand Stecken”-Methode
   Einfach weitermachen wie bisher. Google Analytics via GTM einbinden, Facebook- und ein paar sonstige Retargeting-Pixel laden. Die veralteten Datenschutzbestimmungen, vielleicht noch aus Pre-DSGVO-Zeiten stehen lassen. Etliche Tools, Services und Plugins verwenden, die die gesammelten Daten quer über das Internet über diverse SaaS- und Cloud-Dienste verteilen. Maximal einen einfachen Cookie-Hinweis (natürlich kein Consent) einbinden und jeden Tag beten, dass das “Problem” von selbst verschwindet.
   
   Ausblick: Es wird nur eine Frage der Zeit sein, bis einem diese Methode um die Ohren fliegt. Die Risiken steigen, die zu erwarteten Kosten ebenso. Entweder weil man “erwischt” wird und hohe Strafen winken oder weil man irgendwann doch gezwungen wird tätig zu werden (Rüge vom Landesdatenschutz-beauftragten, Abmahnung von Wettbewerbern oder Verbraucherschützern, etc.). Tritt der Fall ein, muss übereilt gehandelt werden. Alles wird erst einmal ad-hoc “ausgebaut”, um weiteren Schaden zu vermeiden. Folge: Es tritt ein temporärer Blindflug ein – dann muss plötzlich alles was man eben nicht tun wollte, ganz schnell umgesetzt werden. Das kostet Zeit und Geld und verursacht garantiert Probleme und Fehler. Höchstwahrscheinlich weichen die Reports anschließend von den alten Reports ab und man kann sich die Abweichung nicht erklären. Es existieren ja keine  Vergleichskennzahlen aus einem A/B-Test.
   
   Diese Methode ist aller Wahrscheinlichkeit nach die ineffizienteste Methode.
   
   
2. Die „Minimum-Maximum“-Methode
   Bei dieser Methode geht es darum mit minimalem Aufwand das Maximale herauszuholen. Man lässt im Grunde alles wie es ist und baut lediglich einen Consent-Layer vor seine Seite. Der Cookie-Layer ist natürlich auf maximale Consent-Rate optimiert und verwendet jeden Trick den es gibt, um dies zu erreichen. Man orientiert sich an allen anderen und setzt maximal das Minimum um, um nicht aufzufallen und den Ist-Zustand möglichst lange beizubehalten. Alles bleibt wie es ist – naja, gut da ist dieser nervige Cookie-Layer – aber den haben ja auch alle anderen. Der User ist sowieso schon genervt und wird automatisch “Akzeptieren” klicken. Danach läuft ja alles wie gehabt – man wird schon nicht der erste sein, den es erwischt.
   
   Ausblick: Hört sich doch eigentlich super an? Tatsächlich gibt es diese Methode nicht. Man erreicht weder das eine noch das andere. Es ist der berühmte Kampf gegen die Windmühlen. Letztendlich löst man keines der Probleme. Privacy-Blocker (ITP/ETP) blockieren immer mehr Cookies und die Conversion-Raten nehmen gefühlt von Tag zu Tag ab. Gleichzeitig steigt das Risiko – nicht unbedingt, dass man als Erster “erwischt” wird, aber dass die eine große Änderung kommt, vor der alle Angst haben. Es spielt keine Rolle welche es ist – sei es ITP Version X, Cookie-Layer die gleichwertige Buttons haben müssen oder ein Update des Chrome-Browsers der irgendetwas Unvorhersehbares mit sich bringt. Wenn das Update angekündigt ist, rinnt einem die Zeit davon. Auf einmal hat dieses Thema die allerhöchste Priorität und alle anderen Projekte stehen still.
   
   Diese Methode kann funktionieren, wenn die Veränderung ausbleibt oder nur lang genug hinausgezögert wird. Letztendlich schiebt sie das Unvermeidbare aber nur auf. Experten dieser Methode die einem “garantiert” weiterhelfen können, findet man in vielen anderen Branchen: Finanzinstitute, Automobil, (klassischer) Einzelhandel.
   
   
3. Die „Ärmel hochkrempeln“-Methode
   Bei dieser Methode wird das Thema ganzheitlich angegangen. Es wird analysiert welche Daten wo, wie und mit welchen Tools erfasst werden. Anschließend findet ein Audit jedes Tools statt. Gibt es europäische Alternativen (wg. Privacy-Shield)? Können die Daten anonymisiert oder zumindest pseudonymisiert werden, bevor sie übertragen werden? Ist ein Consent nötig für den Einsatz und falls ja wie ist der Kosten-/Nutzen des Tools auch unter Berücksichtigung der Daten und des Risikos des Attributions-Verlustes? Gibt es technische Möglichkeiten das Tracking auch ohne Standard-Implementierung umzusetzen (Stichwort: Server-Side-Tracking)? Ziel des Audits ist es:
   
   a) die Risiken zu minimieren (Juristisch & Organisatorisch)
   b) die Attribution zu verbessern (Technisch & Usability)
   
   Ausblick: Bei dieser Methode entsteht ein sehr hoher Initialaufwand. Das Zusammensuchen und Dokumentieren aller Tools ist mühselig. Auch auf die Entwickler kommt ein hoher Implementierungsaufwand zu – Datenflüsse müssen analysiert, APIs überarbeitet, Cronjobs erweitert oder angepasst werden. Daher ist es am Besten diese Tasks direkt in die Entwickler-Sprints miteinfließen zu lassen, sie Step-by-Step umzusetzen.
   
   Sollte sich meine Hypothese bewahrheiten und Datenschutz tatsächlich “The next big thing” werden, wird man froh darüber sein, das frühzeitig und parallel zum aktuellen Tracking-Setup umgesetzt zu haben. So kann man die Zahlen sehr gut mit den Ist-Zahlen vergleichen und Abweichungen erkennen und verstehen. Liege ich mit meiner Annahme dagegen falsch und die Datenschutz-Diskussion flacht ab bzw. wird entschärft, hat man zugegebenermaßen vermutlich nur Karma-Punkte gesammelt und hätte sich diesen Mehraufwand sparen können.

• UTM-Parameter prüfen und sicherstellen, dass diese überall verwendet werden.
  Der Punkt ist eigentlich allgemein bekannt, wird aber nachwievor leider zu oft unterschätzt. Viel wichtiger und neu ist jedoch, dass die UTM-Parameter auch stringent in die eigene Systemlandschaft integriert werden sollten – also nicht nur einfach via Google Analytics verarbeiten lassen. Dazu zählt, die UTM-Parameter auch selbst abzurufen und in eine eigene Session/Cookie zu speichern und bei Abschluss des Funnel (z.B. Anmeldung, Bestellung, etc.) diese auch entsprechend mit zu speichern. Dies kann später für Offline-Tracking-Implementierungen praktisch sein.
  
  
• Auf Tracking- und Cookie-Weichen verzichten ODER diese korrekt implementieren.
  Wie bereits in “Wie der Google Tag-Manager und Cookie-Weichen das Tracking verfälschen” erwähnt, gibt es viele gute Tracking-Anbieter auf dem Markt. Probleme entstehen aber zumeist, wenn der Kunde die notwendigen Anpassungen nicht oder zu spät umsetzt. Daher unbedingt das aktuelle Setup prüfen und, sofern mit einem Drittanbieter gearbeitet wird, nach aktuellen Updates fragen.
  
  
• Web-Analyse neu aufstellen.
  Die Zeiten in denen einfach nur ein JavaScript von GTM und GA integriert werden und alles läuft, sind vorbei. AdBlocker, ITP & ETP sorgen dafür, dass diese einfach blockiert oder zumindest die Cookies beschnitten werden. Die Anforderungen der DSGVO und die Auswirkungen von Cookie-Layern sind hier noch nicht mal berücksichtigt. Besser: Alternative Tracking-System aufbauen. Entweder mit On-Promise-Lösungen wie Matomo oder durch serverseitiges Tracking via Google Analytics Measurement Protocol.
  
  
• Mehr serverseitig tracken.
  Aktuell ist serverseitiges Tracking in aller Munde – oft wird das Interesse daran damit begründet, dass man nicht mehr von AdBlockern geblockt wird. Ich denke aber serverseitiges Tracking hat noch einen wesentlich größeren Vorteil: Man erhält die Kontrolle über seine Daten zurück! Dass der Trend in diese Richtung geht, hat selbst Google erkannt – nicht umsonst gibt es seit kurzem die Möglichkeit GTM serverseitig zu implementieren. Eine Anleitung dazu liefert Markus Baersch in seinem Artikel “Serverseitiges Tagging mit Google Tag Manager: Erste Eindrücke” (P.S. in seinem Blog gibt es sehr viele gut und detailierte Beiträge – wer sich dafür interessiert – unbedingt lesen!). Serverseitiges Tracking funktioniert übrigens auch bei Google Ads Conversion-Tracking und vielen weiteren Diensten. Daher mein Tipp: einfach mal prüfen welcher der genutzten Dienste auch APIs anbietet, die ggf. anstelle der Standard-JavaScript-Lösung genutzt werden können.
  
  
• Marketing-Kanäle neu aufstellen und Kampagnen-KPIs neu interpretieren.
  Durch immer weiter steigende Tracking-Verluste (siehe Artikel 2-6 dieser Artikelreihe) ist es nicht mehr zeitgemäß den erfassten Zahlen 1:1 blind zu vertrauen. Es ist wichtig die Kanäle einzeln zu analysieren und auch einer Risikobewertung zu unterziehen. Dazu zählt beispielsweise die Wahrscheinlichkeit, dass der Kanal wegbricht oder aber die Abweichung überdurchschnittlich stark von der Attributions-Problematik betroffen ist oder sein wird. Nehmen wir als Beispiel das Retargeting, das von der Abschaffung von Third-Party-Cookies bekannterweise extrem stark betroffen. Bereits heute werden diese Cookies überproportional häufig geblockt – darüber hinaus ist auf der Webseite ein Consent notwendig. Jede Blockierung des Cookies führt somit zu einem Attributions-Verlust. Natürlich gibt es Attributions-Verluste auch bei anderen Kanälen – diese sind in der Regel aber niedriger als die des Retargetings. Es macht also keinen Sinn pauschal bei jedem Kanal 50% hinzuzurechnen. Vielmehr muss jeder Kanal einzeln bewertet werden und seinen eigenen “Messverlust-Aufschlag” erhalten. Erst dann ist ein Vergleich der einzelnen Kampagnen-Erfolge und somit die Skalierungs-Entscheidung möglich.
  
  
• Hinterfragt euren Direct-Traffic.
  Eigentlich ein alter Schuh, aber aufgrund der Wichtigkeit und der vielen Fragen nach “Wie hoch ist denn nun normal?” nochmals explizit: Ein Direct-Traffic-Anteil von >50% heißt nicht zwangsläufig, dass man eine “extrem starke Brand” hat. Es bedeutet, dass man entweder ein extrem schwaches Marketing hat oder viel wahrscheinlicher, ein extrem starkes Tracking-Problem. Dies wiederum bedeutet, dass die Conversions, die in Direct auftauchen zu einem großen Teil anderen Kanälen zugerechnet werden müssen – die Frage ist nur zu welchen.

• Technology (e.g. AdBlocker)
• Legal (GDPR)
• Usability (Cross-Device/-Browser)

• Office/Collaboration: G-Suite, Microsoft 365, …
• Project management: Asana, Trello,…
• Messenger: Slack, MS Team,…
• E-Mail: Mailchimp, Sendgrid,…
• CRM: Salesforce, Zoho,…
• Data-Migration: Funnel.io, Segment, Stitch,…
• Monitoring: Sentry, Datadog,…
• and many more

1. The „head in the sand“ method
   Just carry on as before. Integrate Google Analytics via GTM, load Facebook and a few other retargeting pixels. Leave the outdated data protection regulations, perhaps from pre-DSGVO times. Use a number of tools, services and plugins that distribute the collected data across the Internet via various SaaS and cloud services. Include at most a simple cookie hint (of course, no content) and pray every day that the „problem“ disappears by itself.
   
   Outlook: It will only be a matter of time before this method blows up in your face. The risks are increasing, as are the expected costs. Either because one is „caught“ and high penalties beckon or because one is forced to take action at some point (reprimand from the state data protection officer, warning from competitors or consumer protection agencies, etc.). If the case occurs, one must act hastily. Everything is first of all „expanded“ ad-hoc to avoid further damage. Consequence: A temporary blind flight occurs – then suddenly everything that one did not want to do must be implemented very quickly. This costs time and money and is guaranteed to cause problems and errors. Most likely, the reports then deviate from the old reports and the deviation cannot be explained. There are no comparative figures from an A/B test.
   
   This method is probably the most inefficient method.
   
   
2. The „Minimum-Maximum“ method
   This method is all about getting the maximum out of a situation with minimum effort. Basically you leave everything as it is and just put a content layer in front of your page. The cookie layer is of course optimized for maximum content rate and uses every trick there is to achieve this. You orientate yourself on all the others and use the minimum to avoid attracting attention and keep the actual state as long as possible. Everything stays as it is – well, well there is this annoying cookie layer – but everyone else has it too. The user is already annoyed anyway and will automatically click „Accept“. After that, everything runs as usual – you won’t be the first one to get it.
   
   Outlook: Sounds great, doesn’t it? In fact, this method does not exist. You can achieve neither one nor the other. It is the famous fight against the windmills. In the end you don’t solve any of the problems. Privacy blockers (ITP/ETP) are blocking more and more cookies and the conversion rates are decreasing noticeably from day to day. At the same time the risk increases – not necessarily that you will be the first to be „caught“, but that the one big change will come that everyone is afraid of. It doesn’t matter what it is – be it ITP version X, cookie layers that must have equivalent buttons, or a chrome browser update that brings something unpredictable. When the update is announced, you run out of time. All of a sudden this issue has the highest priority and all other projects stand still.
   
   
3. The „roll up your sleeves“ method
   This method takes a holistic approach to the topic. It analyzes which data is collected where, how and with which tools. An audit of each tool is then carried out. Are there European alternatives (e.g. privacy shield)? Can the data be anonymized or at least pseudonymized before it is transferred? Is a consensus necessary for the use and if so, what is the cost/benefit of the tool, also considering the data and the risk of attribution loss? Are there technical possibilities to implement the tracking even without standard implementation (keyword: server-side-tracking)? The goal of the audit is
   
   a) to minimize the risks (legal & organizational)
   b) to improve the attribution (technical & usability)
   
   Outlook: This method requires a very high initial effort. The collection and documentation of all tools is laborious. Developers also have to put a lot of effort into implementation – data flows have to be analyzed, APIs have to be revised, cronjobs have to be extended or adapted. Therefore, it is best to incorporate these tasks directly into the developer sprints, implementing them step-by-step.
   
   Should my hypothesis prove to be true and data protection really become „The next big thing“, one will be glad to have implemented this early and parallel to the current tracking setup. This way you can compare the figures with the actual figures very well and detect and understand deviations. On the other hand, if I am wrong with my assumption and the data protection discussion flattens out or is defused, one has admittedly probably only collected karma points and could have saved oneself this additional effort.

• Check UTM parameters and ensure that they are used everywhere.
  The point is actually generally known, but unfortunately it is still too often underestimated. What is much more important and new, however, is that the UTM parameters should also be stringently integrated into your own system landscape – i.e. not just be processed via Google Analytics. This includes calling up the UTM parameters yourself and saving them in a separate session/cookie and saving them accordingly when the funnel is completed (e.g. login, order, etc.). This can be useful later for offline tracking implementations.
  
  
• Do not use tracking- or cookie switches OR implement them correctly.
  As already mentioned in „How the Google Tag Manager and cookie switches falsify tracking„. However, problems usually arise if the customer does not implement the necessary adjustments or does so too late. Therefore it is essential to check the current setup and, if you are working with a third party provider, ask for the latest updates.
  
  
• Reorganize web analysis.
  The times when simply integrating a JavaScript from GTM and GA and everything is running are over. AdBlocker, ITP & ETP ensure that these are simply blocked or at least the cookies are cut. The requirements of the DSGVO and the effects of cookie layers are not even considered here. Better: Set up alternative tracking system. Either with on-promise solutions like Matomo or by server-side tracking via Google Analytics Measurement Protocol (German).
  
  
• More server side tracking.
  Currently, server-side tracking is on everyone’s lips – often the interest in it is justified by the fact that one is no longer blocked by AdBlockers. But I think server-side tracking has an even bigger advantage: You get back control over your data! Even Google has recognized that the trend goes in this direction – it is not without reason that there is the possibility to implement GTM server-side. Markus Baersch provides instructions for this in his article „Server-side tagging with Google Tag Manager: First impressions (German)“ (P.S. in his blog there are many good and detailed articles – if you are interested – read them!) Server-side tracking also works with Google Ads Conversion-Tracking (German) and many other services. So my tip: just check which of the used services also offers APIs that can be used instead of the standard JavaScript solution.
  
  
• Reposition marketing channels and reinterpret campaign KPIs.
  Due to ever increasing tracking losses (see article 2-6 of this series of articles) it is no longer up-to-date to blindly trust the captured numbers 1:1. It is important to analyze the channels individually and also to subject them to a risk assessment. This includes, for example, the probability that the channel will break away or that the deviation is or will be affected to an above-average degree by the attribution problem. Let’s take retargeting as an example, which is known to be extremely affected by the elimination of third-party cookies. Already today, these cookies are blocked disproportionately often – in addition, a consensus is necessary on the website. Each blocking of the cookie thus leads to a loss of attribution. Of course, there are attribution losses also with other channels – but these are usually lower than those of retargeting. So it makes no sense to add 50% to each channel. Rather, each channel must be evaluated individually and receive its own „measurement loss markup“. Only then is it possible to compare the individual campaign successes and thus make a scaling decision.
  
  
• Question your direct traffic.
  Actually an old shoe, but due to the importance and the many questions about „How much is normal?“ again explicitly: A direct traffic share of >50% does not necessarily mean that you have an „extremely strong brand“. It means that you either have an extremely weak marketing or, more likely, an extremely strong tracking problem. This in turn means that the conversions that appear in Direct are largely attributable to other channels – the question is to which ones.