Yandex Direct: den Weg von der Anzeige zum Verkauf prüfen

Wenn Yandex Direct Anfragen liefert, aber der Vertrieb keine Aufträge gewinnt, kommt die Empfehlung „Zielgruppe wechseln“ zu früh. Ein Interessent sieht vielleicht die Zusage eines Besuchs am selben Tag, landet auf einer Seite mit einer anderen Leistung und hört nach dem Absenden seiner Telefonnummer wieder andere Bedingungen. Die einzelnen Werkzeuge funktionieren: Die Anzeige läuft, das Formular wird abgeschickt, das CRM legt einen Datensatz an. Trotzdem passt der Ablauf nicht zusammen.

Das Ergebnis dieses Audits ist ein konkreter Fehlerbericht: An welchem Übergang ging eine Zusage oder Handlung verloren, welcher Beleg zeigt das, wer behebt den Fehler und welcher Wiederholungstest bestätigt die Korrektur? Die Anleitung richtet sich an Werbetreibende für den russischen Markt. Sie ist keine allgemeine Einführung in Metrica oder den Abgleich von Statistiken. Russland bleibt in allen Übersetzungen das Untersuchungsgebiet. Offizielle Quellen wurden am 25. Oktober 2026 geprüft. Vorlagen, Schwellenwerte und beide Beispiele sind unsere redaktionelle Methode, keine Vorgaben von Yandex.

Festlegen, was genau nicht funktioniert

Wählen Sie eine Kombination aus Anzeigengruppe, Leistung, Stadt, Landingpage und Kontaktweg. Suchanfragen mit nachvollziehbarer Absicht eignen sich für den ersten Durchgang. Trennen Sie diese von Traffic aus dem Yandex-Werbenetzwerk, Bestandskunden und anderen Leistungen. Wählen Sie einen abgeschlossenen Zeitraum mit unveränderten Angebotsbedingungen und dokumentieren Sie den Beobachtungsstichtag. Ein noch laufender langer Verkaufsprozess ist keine Ablehnung.

Benötigt werden Anzeigen und Zieladressen, Berichte aus Direct und Metrica, eine technische Formularprüfung, anonymisierte CRM-Verläufe und eine verantwortliche Vertriebsleitung. Sichern Sie Versionen von Anzeigentext, erstem Seitenabschnitt, Formular und Gesprächseinstieg. Hinzu kommen Öffnungszeiten, tatsächliches Einsatzgebiet sowie verfügbare Produkte oder Fachkräfte. Ohne Versionshistorie beweist die heutige Seite nicht, was ein Besucher gestern gesehen hat. Kennzeichnen Sie diese Grenze.

Definieren Sie vier Ebenen. Ein Ereignis ist ein Analysesignal. Eine Anfrage ist tatsächlich beim Unternehmen eingegangen. Ein akzeptierter Lead erfüllt die zum Anfragezeitpunkt geltenden Bedingungen und kann bearbeitet werden. Ein beständiger Verkauf ist ein erfüllter und bezahlter Auftrag nach dem im Beispiel vorgesehenen Stornozeitraum. Eine spätere Kaufabsage macht einen akzeptierten Lead nicht automatisch ungültig. Für Partnervergütungen gilt ein separat vereinbartes Ereignis.

Wenn Sie zusätzlich einen Partnerkanal vorbereiten, registrieren Sie sich als Werbetreibender bei AffiliateCore und formulieren Sie Ihr Angebot mit geprüfter Landingpage. Unsere Plattform ermöglicht Angebotsentwürfe mit Name, Beschreibung und Landingpage-URL. Produkt und Trafficquelle benötigen eine separate Zulässigkeitsprüfung. Das Direct-Audit erfolgt in Ihren Werbewerkzeugen und Ihrem CRM; eine eingebaute Synchronisierung dieser Kette wird hier nicht zugesagt.

Fünf Übergänge anhand von Belegen prüfen

1. Suchanfrage → Anzeigenversprechen

Der offizielle Suchanfragenbericht von Direct zeigt auslösende Suchanfragen. Vergleichen Sie die verfügbaren Angaben mit Leistung, Ort, Termin und Einschränkungen der Anzeige. Verwechseln Sie Suchanfrage und gebuchtes Keyword nicht. Ohne nachgewiesene Einzelzuordnung dürfen Sie einer bestimmten Person keine Suchanfrage zuschreiben; bleiben Sie auf der verfügbaren Segmentebene.

Erstellen Sie drei Spalten: Erwartung des Besuchers, Versprechen der Anzeige und tatsächlich lieferbare Leistung. „Reparatur heute“ bedeutet nicht „Rückruf heute“. Eine unpassende Suchanfrage erfordert eine Prüfung der Aussteuerung. Eine passende Anfrage mit unerfüllbarem Versprechen erfordert eine Angebotskorrektur. Das sind unterschiedliche Fehler, auch wenn beide mit einer Absage durch den Vertrieb enden.

2. Anzeige → Landingpage

Öffnen Sie die gespeicherte Zieladresse direkt, statt wiederholt auf Ihre eigene laufende Anzeige zu klicken. Prüfen Sie Desktop und Mobilgerät, Hauptziel und zusätzliche Links, Formular und Telefonkontakt. Vergleichen Sie den ersten Seitenabschnitt mit der Anzeige: Eine wesentliche Einschränkung darf nicht erst im Gespräch auftauchen. Notieren Sie Datum, Version, Gerät und erwartetes Prüfergebnis.

Yandex empfiehlt, URLs mit yclid auf Funktion zu prüfen und dadurch ausgelöste Websitefehler zu beheben: Dokumentation zu Direct und Metrica. Untersuchen Sie zusätzlich das endgültige Ziel nach Weiterleitungen und den Erhalt des Leistungskontexts. Ein verlorener Parameter begründet eine Messprüfung, beweist allein aber keinen verlorenen Verkauf.

3. Formular → eingegangene Anfrage

Ein Formularziel kann auch einen erfolglosen Versuch erfassen; das erläutert die Metrica-Hilfe. Testen Sie ein leeres Formular, eine ungültige Nummer, eine gültige Übermittlung und einen erneuten Klick getrennt. Dokumentieren Sie sichtbare Antwort, Eingang beim Unternehmen und CRM-Datensatz. Eine Dankesmeldung ersetzt keinen Speichernachweis.

Metrica unterstützt Zielereignisse über reachGoal: offizielle Beschreibung. Unsere Empfehlung lautet, das gewünschte Ereignis durch einen Entwickler an die bestätigte Speicherung zu binden, statt nur an einen Klick. Das ist eine Anpassung Ihrer Website und keine allgemeingültige Reparatur per Kontrollkästchen. Markieren Sie Tests und schließen Sie sie aus Geschäftsergebnissen aus.

Yandex beschreibt _ym_debug=2 und das Debugging-Panel für den neueren Zählercode in der Zielprüfung. Für den Nachweis einer Korrektur brauchen Sie sowohl das richtige Ereignis als auch den Datensatz beim Unternehmen. Telefonnummern, E-Mail-Adressen und Gesprächsinhalte gehören weder in Diagnose-URLs noch in offene Auditdokumente.

4. Kontakt → verantwortlicher Mitarbeiter

Ein Telefonklick beweist kein Gespräch. Anrufdaten werden über separates Calltracking an Metrica übertragen: offizielle Anleitung. Fehlt dieses System, nutzen Sie vorhandene Telefonprotokolle und lassen die Zuordnung zu einem bestimmten Werbebesuch ausdrücklich offen. Bei Formularen prüfen Sie Eingang, Zuweisung und Zeitpunkt der ersten inhaltlichen Antwort.

Wer übernimmt zum Schichtende, bei Abwesenheit der üblichen Person oder bei einer selten angefragten Leistung? Eine Nachricht im Gruppenchat ist noch keine Zuständigkeit. Verfolgen Sie mehrere Datensätze: Sieht der Mitarbeiter die zugesagten Bedingungen, die gewünschte Leistung und den bevorzugten Kontaktweg? Eine ausbleibende Kundenantwort beweist weder eine falsche Nummer noch schlechten Traffic.

5. Antwort → Angebot → Ergebnis

Vergleichen Sie Gesprächseinstieg und Werbung. Wurde die versprochene Handlung angeboten, der Preis vor einer Zusage erklärt und ein nächster Schritt vereinbart? Ordnen Sie jedem verlorenen Verkauf eine belegbare Ursache zu: kein Termin, andere Leistung, ungeeignetes Angebot, Kundenabsage oder unbekannt. Ersetzen Sie unbekannte Ursachen nicht bequem durch „unqualifiziert“.

Vorlage zur Nachverfolgung: interne ID; Zeit und Zeitzone; Anzeigengruppe; Version des Versprechens; Landingpage; Kontaktweg; Eingangsbeleg; Verantwortlicher; erste Antwort; nächster Schritt; Ergebnis; Grund; zugänglicher Beleg; unbekannte Felder. Kontaktdaten verbleiben im regulären System mit eingeschränkten Zugriffsrechten. Für einen Entwickler reichen meist technische ID und reproduzierbare Bedingungen.

Öffentlicher Fall Skillfactory: Wann ist eine Anfrage qualifiziert?

Yandex beschreibt bei Skillfactory (20. Februar 2024) eine CRM-Prüfung ohne Dubletten. Qualifizierte Anfragen sind keine bezahlten Verkäufe; der Anbieterbericht wurde hier nicht unabhängig geprüft. Yandex.

Unsere Anwendung im Audit: Untersuchen Sie die Grenze zwischen Dateneingang und Annahme zur Bearbeitung. Schreiben Sie die Qualifikationsregel vor der Ergebnisprüfung auf. Sonst lassen sich erfolglose Verkäufe nachträglich als schlechte Leads umdeuten. Fordern Sie eine zugriffsbeschränkte Belegkette aus ursprünglicher Anfrage, Prüfentscheidung und späterem Auftragsergebnis an. Ohne diese bleiben Verkäufe, Stornos und kausale Verbesserungen unbestätigt. Das ist unser Prüfvorschlag, keine Rekonstruktion interner Skillfactory-Abläufe oder Aussage über die heutige Konfiguration. Übernehmen Sie historische Integrationseinstellungen erst nach Prüfung der aktuellen Dokumentation.

Lernbeispiel 1: dringende Reparatur ohne heutigen Termin

Ein erfundener Haushaltsgeräte-Reparaturbetrieb in Kasan wirbt mit einem Besuch heute. Die Seite fordert eine Reparaturanfrage an, tatsächlich ist erst in mehreren Tagen ein Termin frei. Untersucht werden eine Suchanzeigengruppe und eine Leistung. Die Erhebung dauert sieben Tage, die Beobachtung bis Tag 21 ab Beginn; dann sind im Beispiel alle Vorgänge abgeschlossen. Dies sind keine Kundenergebnisse und keine universelle Frist.

Vorher: Anzeige „Techniker heute“, erster Seitenabschnitt ohne Verfügbarkeitsprüfung, Telefonformular und Antwort „heute ist nichts frei“. Nachher: Anzeige „Reparatur nach Termin – Verfügbarkeit anfragen“, entsprechender Seitenbeginn, Formular „Termin prüfen“ und Gesprächseinstieg „Sie haben einen Termin angefragt; wir prüfen Gebiet, Defekt und das nächste freie Zeitfenster“. Dringlichkeit darf nur zugesagt werden, wenn sie erfüllbar ist.

Der Test startet an der mobilen Zieladresse. Ein Mitarbeiter prüft fehlerhafte und gültige Eingaben, anschließend genau einen Arbeitsdatensatz, die gewünschte Leistung und den zugewiesenen Bearbeiter. Eine Anfrage am Schichtende wird separat geprüft. Erfolg bedeutet gespeicherter Kontext und ein verständlicher nächster Schritt. Testanfragen sind weder vergütete Ergebnisse noch Teil der Geschäftskohorte.

Trennen Sie im Lernprotokoll wiederholte Kontakte zum selben Reparaturauftrag, andere Leistungen, nicht hergestellten Kontakt und akzeptierte Anfragen. Verknüpfen Sie Wiederholungen mit dem Original, ohne den Verlauf zu löschen. Wer den angebotenen Termin ablehnt, kann dennoch einen gültigen Lead geliefert haben. Dokumentieren Sie Erfüllung und spätere Stornierung getrennt: Eine akzeptierte Anfrage darf bei einem gescheiterten Verkauf nicht aus der Historie verschwinden.

Als Beleg dienen das gesicherte Heute-Versprechen und eine zulässig verwendete Notiz zum fehlenden Termin. Leiten Sie den Grund nicht aus einer sinkenden Konversionskurve ab. Andere Absagegründe gehören nicht in diese Gruppe. Korrigieren Sie Zusage und Terminabstimmung; prüfen Sie anschließend mit dem Arbeitsblatt, ob der zuständige Mitarbeiter die ursprüngliche Aufgabe sieht.

Pausieren Sie den betroffenen Weg bei unerfüllbarem Versprechen oder verlorener gültiger Formularanfrage. Wiederholen Sie nach Korrektur den Weg auf Computer und Mobilgerät einschließlich Übergabe am Schichtende. Ein begrenzter Pilot darf weiterlaufen, wenn Zusage, Eingang und Zuständigkeit geprüft sind und die Termine tatsächlich bedient werden können. Offene Aufträge bleiben bis zum vereinbarten Stichtag offen. Technischer Testerfolg beweist kein Verkaufswachstum.

Lernbeispiel 2: angefragte Kalkulation, falsches Verkaufsgespräch

Ein erfundener Büroausstatter in Jekaterinburg gewinnt Anfragen für kleine Büros. Anzeige und Seite bieten eine Kalkulation nach Zahl der Arbeitsplätze. Das Formular speichert Telefonnummer und Anzahl, die Benachrichtigung des Mitarbeiters enthält diesen Kontext jedoch nicht. Er beginnt mit dem Verkauf eines Einzelgeräts. Technisch sind die Anfragen angekommen; die Übergabe der Kundenaufgabe ist fehlerhaft.

Benachrichtigungsvorlage: „Anfrage für Ausstattungspaket; ID; Arbeitsplatzanzahl; gewählte Kategorie; Landingpage-Version; bevorzugter Kontakt; Verantwortlicher; nächste Handlung“. Erste Antwort: „Sie haben eine Ausstattung für die angegebene Arbeitsplatzanzahl angefragt. Wir klären Zusammenstellung und Einschränkungen und vereinbaren anschließend, wann Sie die Kalkulation erhalten“. Nicht übermittelte Angaben bleiben unbekannt, statt geschätzt zu werden.

Prüfen Sie zwei gültige Anfragen verschiedener Kategorien und eine Wiederholung. Der Mitarbeiter muss die ursprüngliche Aufgabe sehen, den richtigen Datensatz öffnen und einen nächsten Schritt festlegen. Wiederholungen werden nach Unternehmensregeln verknüpft. Den Übertragungsweg bestimmt der CRM-Verantwortliche; ein bestimmter Konnektor wird nicht vorausgesetzt. Änderungen der Zuständigkeit werden getrennt von Seitentextänderungen getestet.

Legen Sie getrennte Lernaufzeichnungen für eine wiederholte Kalkulationsanfrage, ein nicht angebotenes Produkt, fehlenden Kontakt und eine akzeptierte Paketanfrage an. Eine akzeptierte Anfrage kann später verloren gehen oder storniert werden, ohne ungültig zu werden. Bewahren Sie die erste Qualifikationsentscheidung auf und ergänzen Sie das Auftragsergebnis. Prüfen Sie die erste Antwort, bevor Sie fehlenden Kontext als Verlustursache nennen; andere Gründe bleiben unterscheidbar.

Die Leitung vergleicht zunächst Formulartext, Datensatz und erstes Angebot. Steht die Arbeitsplatzanzahl im CRM, wurde aber ignoriert, liegt der Fehler in der Bearbeitung. Fehlt sie bereits in der gespeicherten Anfrage, muss der Formularverantwortliche untersuchen. Daraus folgen unterschiedliche Korrekturen: Schulung und Zuständigkeit oder Wiederherstellung der Feldübertragung.

Pausieren Sie den betroffenen Weg, wenn Pflichtkontext fehlt oder niemand die Übergabe übernimmt. Prüfen Sie nach Korrektur verschiedene Kategorien, eine Wiederholung und die Vertretungszuweisung. Fortsetzen ist erst sinnvoll, wenn der Mitarbeiter die ursprüngliche Aufgabe erklären und den zugesagten nächsten Schritt festhalten kann. Erweitern Sie nur bei ausreichender Angebotskapazität und ohne offene Übertragungsfehler. Ein Angebot bleibt vom erfüllten Auftrag getrennt.

Für ein separates Partnerangebot melden Sie sich im AffiliateCore-Werbekonto an und übertragen Sie geprüfte Beschreibung und URL in Ihren Angebotsentwurf, sofern die Erstellung Ihrem Konto offensteht. Halten Sie Annahmebedingungen zuerst in einem Arbeitsbriefing fest. CRM, Direct und Antwortzeiten bleiben Ihre operative Verantwortung. Die Beispielaufträge werden nicht als automatisch unterstützte vergütbare Plattformereignisse dargestellt.

Kopiervorlage für die CRM-Übergabe

Kopieren Sie das folgende Blatt in ein zugriffsbeschränktes Arbeitsdokument. Stimmen Sie das Testfenster mit Formularverantwortlichen und Vertriebsleitung ab. Nutzen Sie autorisierte Testkontakte, die außerhalb dieses Blatts bleiben, und markieren Sie jeden Test. Füllen Sie zuerst die Übergabevereinbarung aus, führen Sie dann die Prüffälle aus und ergänzen Sie bereinigte Eingangsbelege oder Datensatzreferenzen. Nutzen Sie nach Möglichkeit eine Testumgebung. Simulieren Sie einen Übertragungsfehler dort oder untersuchen Sie einen bestehenden freigegebenen Vorfall; beschädigen Sie keine laufende Integration für einen Nachweis. Tests dürfen weder vergütete Conversions noch Trainingssignale für kommerzielle Optimierungsziele werden. Das Blatt ist eine redaktionelle Vorlage, keine AffiliateCore-Integration.

Arbeitsblatt als Textdatei herunterladen

CRM-ÜBERGABE — ARBEITSKOPIE
Geltungsbereich: Russland / Yandex Direct; Sprache belegt keine Verfügbarkeit.
Keine Namen, Kontaktdaten, Zugangsdaten oder Gesprächsabschriften eintragen.

LEERE ÜBERGABEVEREINBARUNG
Weg / Leistung / Landingpage-Version: ____
Anzeigenversprechen / zulässige Ausnahmen: ____
Testumgebung / freigegebenes Testfenster: ____
Auditreferenz / Eingangszeit und Zeitzone: ____
Eingangsbestätigung / CRM-Datensatzreferenz: ____
Pflichtkontext / tatsächlich vorhandene Werte: ____
Verantwortlicher / Vertretung / nächste Handlung / Frist: ____
Qualifikationsregel und Version: ____
Entscheidung: akzeptiert / abgelehnt / Dublette / unbekannt: ____
Grund / Beleg / Prüfer / Entscheidungszeit: ____
Dublettenregel / ursprüngliche Datensatzreferenz: ____
Auftrag: offen / verloren / erfüllt / storniert: ____
Ergebnisbeleg / Beobachtungsstichtag: ____
Unbekanntes / zuständige Prüfperson: ____
Fehler / Korrekturversion / Wiederholungsbeleg: ____
Entscheidung: bestanden / nicht bestanden / Stopp; Entscheider: ____

AUSGEFÜLLTES LERNBEISPIEL — ERFUNDEN, KEINE KUNDENERGEBNISSE
Weg: Büroausstattung als Paket; Landingpage-Version B.
Referenz: TEST-B; Zeit: vereinbartes Testfenster, Europe/Moscow.
Versprechen: vollständige Ausstattung für Arbeitsplätze besprechen.
Pflichtkontext: Paketkategorie; bevorzugter Antwortkanal.
Eingangsbeleg: TEST-RECEIPT-B; CRM-Referenz: TEST-CRM-B.
Beobachtung: Kategorie gespeichert, fehlt aber in der Mitarbeiterbenachrichtigung.
Verantwortlicher: Testleitung Vertrieb; Vertretung: Schichtleitung.
Entscheidung: akzeptierte Testanfrage; kein Verkauf.
Grund: Leistung im Angebot enthalten, Eingang bestätigt.
Nächste Handlung: vollständigen Datensatz öffnen, Paketwunsch bestätigen.
Auftrag: offen; keine Belege für Erfüllung oder Storno.
Unbekannt: ob andere Benachrichtigungswege die Kategorie verlieren.
Fehlerverantwortlicher: CRM-Administration; Korrektur: Benachrichtigung C.
Wiederholung: zugewiesener Mitarbeiter sieht die Kategorie in der neuen Version.
Entscheidung: vorher nicht bestanden; bestanden erst nach belegter Wiederholung.

PRÜFFÄLLE — ERWARTETE ERGEBNISSE
GÜLTIG: autorisierte Anfrage für eine angebotene Leistung senden.
Erwartet: Eingang, verknüpfter Datensatz, Kontext, Verantwortlicher und nächste Handlung.
UNGÜLTIG: Pflichtfeld auslassen.
Erwartet: sichtbarer Validierungshinweis; keine akzeptierte Geschäftsanfrage.
WIEDERHOLUNG: dieselbe autorisierte Anfrage wiederholen.
Erwartet: dokumentierte Verknüpfung zum Original, kein zweites akzeptiertes Ergebnis.
ANDERE AUFGABE: gleicher Testkontakt, anderer legitimer Bedarf.
Erwartet: Prüfung nach Dublettenregel statt automatischer Löschung.
ABLEHNUNG: Leistung außerhalb des Angebots anfragen.
Erwartet: Grund mit Bezug zur Angebotsversion; Eingangsbeleg bleibt erhalten.
NICHT ERREICHBAR: freigegebenen Fall ohne Antwort prüfen.
Erwartet: unbekannt/kein Kontakt, keine erfundene Betrugsbehauptung.
SCHICHTENDE: vereinbarte Übergabe an die Vertretung prüfen.
Erwartet: zuständige Rolle, Frist und Übernahmebestätigung.
ÜBERTRAGUNGSFEHLER: sicher in einer Testumgebung simulieren.
Erwartet: keine falsche Erfolgsmeldung; wiederherstellbare Belege und Zuständigkeit.

ABNAHME-CHECKLISTE
[ ] Versprechen passt zu tatsächlich lieferbarer Leistung.
[ ] Eingang ist unabhängig vom Analyseereignis belegt.
[ ] Kontext, Zuständigkeit und nächste Handlung bleiben erhalten.
[ ] Dubletten und Ablehnungen haben Gründe und Belege.
[ ] Unbekannte und offene Ergebnisse bleiben sichtbar.
[ ] Tests sind aus Geschäftsergebnissen ausgeschlossen.
[ ] Wiederholungsbelege gehören zur korrigierten Version.
BESTANDEN: Jeder zutreffende Prüffall erfüllt die Erwartung.
NICHT BESTANDEN: Abweichung erfassen, Korrektur zuweisen; nicht erweitern.
STOPP: gültige Anfrage verloren, falsches Versprechen oder kein Verantwortlicher; betroffenen Weg pausieren.
NEUSTART: Korrektur, Wiederholung und Freigabe der Vertriebsleitung sind dokumentiert.

Korrektur und nächsten Pilot dokumentieren

Fehlerkarte: Übergang; erwartete Handlung; tatsächliches Ergebnis; Beleg; bekannte Auswirkungen; Unbekanntes; Verantwortlicher; Änderungsversion; Wiederholungstest; Entscheidung zur Trafficfreigabe. Beispiel: „Landingpage zu Bearbeitung: Verfügbarkeit soll geprüft werden, Mitarbeiter sagt Besuch ungeprüft zu; Gesprächsleitfaden ändern und drei autorisierte Testanfragen prüfen“. Der Testumfang richtet sich nach Risiko und unterschiedlichen Wegen, nicht nach einem eindrucksvollen Bericht.

Ändern Sie nicht gleichzeitig Zielgruppe, Preis, Formular und Vertriebsteam, wenn Sie das Ergebnis verstehen wollen. Beheben Sie zuerst den nachgewiesenen Fehler und führen Sie dann einen vergleichbaren begrenzten Pilot durch. Ein Vorher-nachher-Vergleich beweist keine Kausalität: Nachfrage, Saison und Kapazitäten können sich ändern. Trennen Sie die reproduzierbare Fehlerkorrektur vom noch nicht kausal erklärten Verkaufswachstum.

Arbeitsaufgabe: Wählen Sie einen Weg und verfolgen Sie zehn anonymisierte Anfragen vom Versprechen bis zum Ergebnis, einschließlich Absagen und Stornos. Füllen Sie die Vorlage aus, reproduzieren Sie einen Fehler, benennen Sie einen Verantwortlichen und begrenzen Sie den Wiederholungstest. Prüfen Sie Zusagen, Formulareingang, Datensatzkontext, Zuständigkeit, nächsten Schritt, Ergebnisreife, Stornos und Belege für jede Entscheidung. Fehlen Belege, ist ein präzises Unbekanntes samt Prüfweg ein verwertbares Ergebnis.

Benachbarte Aufgaben behandeln Quellenanalyse in Metrica, Statistikabgleich und zuverlässige CRM-Übermittlung. Dieses Audit liefert einen anderen Abschluss: einen belegten Bruch in einem konkreten Weg und überprüfbare Bedingungen für dessen erneuten Start.