Die direkte Antwort
Ein öffentliches Event ist eine Beobachtung, kein Beweis für Kaufabsicht. Nutze es nur für eine enge Research-Priorität, wenn du exakte Quelle, Datum, zulässige Interpretation, Ablaufregel und eine sichere Aktion festhalten kannst, falls die Hypothese falsch ist.
Stellenausschreibung, Produktlaunch, Expansionsmeldung, Registereintrag oder Führungswechsel können für dein Angebot relevant sein. Keines davon beweist automatisch Budget, Timing, Zuständigkeit, Dringlichkeit oder Kontakterlaubnis. Die Disziplin besteht darin, festzuhalten, was die Quelle sagt, was sie als nächsten Research-Schritt rechtfertigt und was sie nicht beweist.
1. Baue ein Trigger-Evidenzprotokoll
Das Protokoll trennt sichtbar: Evidenz ist das Ereignis; Priorität ist deine interne Entscheidung; Intent wird nicht unterstellt.
2. Nutze Quellenklassen bewusst
Bevorzuge unternehmenseigene oder autoritative Quellen. Eine Drittquelle kann bestätigender Kontext sein, wenn der Feldvertrag den Grund festhält; für eine wesentliche Behauptung reicht sie standardmäßig nicht aus. Startest du mit einem Signal Dritter, suchst du vor einer starken Behauptung Primärevidenz. Seiten können verschwinden; Prüfdatum zählt genauso wie URL.
3. Ergänze veraltet, widersprüchlich und No-Result
Kollabiere nicht auf Ja/Nein. Eine aktuelle direkte Beobachtung kann belegt sein; eine alte Seite ist veraltet; glaubwürdige Quellen, die einander widersprechen, sind widersprüchlich; ohne akzeptable Quelle gilt kein Ergebnis. Jeder Zustand braucht eine andere Aktion. No-Result bedeutet keine Priorität aufgrund dieses Triggers – nicht, dass der Account keine Aktivität hat.
Nutze das Trigger-Evidenzprotokoll
Lade das Trigger-Evidenzprotokoll herunter. Halte pro Beobachtung Quelle und Datum, die eng gestützte Aussage, die verlockende aber ungestützte Schlussfolgerung, eine sichere nächste Aktion und eine Enthaltungsbedingung fest. Weise jeder Zeile eine kontrollierte sample_group zu: signal, no_signal_control, ambiguous oder known_false_positive. Halte die benannte nächste Aktion vor und nach dem Review fest und setze next_action_changed nur auf yes, wenn diese Werte abweichen. Eine Stellenanzeige kann stützen: „Diese Rolle war an diesem Datum öffentlich ausgeschrieben.“ Sie kann allein nicht stützen: „Das Unternehmen kauft Software.“ Das Protokoll macht diese Trennung über einen 20-Account-Pilot prüfbar.
4. Teste, ob ein Trigger nützlich ist
Führe einen zeitlich begrenzten 20-Account-Pilot aus. Nimm Accounts mit Signal, ohne Signal, mit mehrdeutiger Evidenz und bekannte False Positives auf und halte sie als kontrollierte sample_group-Werte im Protokoll fest. Prüfe pro Account unabhängig Fit, Rollenrelevanz und erlaubte nächste Aktion. Zwanzig Accounts sind ein operativer, richtungsweisender Workflow-Pilot – keine statistisch ausreichend große Schätzung von Nachfrage, Umsatz oder kausalem Uplift. Vergleiche belegte Beobachtungen, Reviewer-Übereinstimmung, Accounts mit geänderter Priorität nach vollem Review, False-Priority-Rate und Review-Zeit pro wirklich veränderter Aktion.
Nenne einen Trigger nicht aufgrund einiger positiver Anekdoten „high intent“. Dein Pilot kann zeigen, dass eine Beobachtung in einem Segment und Zeitfenster eine nützliche Research-Priorität ist. Wiederhole ihn bei Quellen-, ICP-, Markt- oder Angebotswechsel.
5. Halte Nachricht und Beobachtung getrennt
Dieser Workflow endet bei einer geprüften Prioritätsentscheidung. Falls später eine Kampagne zulässig ist, hat die Nachricht eigene Evidenz-, Policy- und Freigaberegeln. Verwandle eine Stellenanzeige nicht in eine Personalisierungsbehauptung, die sie nicht stützt. Die nächste sichere Aktion kann mehr Account-Research, eine generische freigegebene Nachricht oder keine Aktion sein.
6. Beginne mit einer Entscheidungsfrage, nicht mit einer Signalliste
Ein nützlicher Trigger-Workflow beginnt mit einer engen Entscheidung, die ein Team verändern kann. Zum Beispiel: „Welche bereits ICP-qualifizierten Accounts verdienen diese Woche einen Company-Review, weil eine aktuelle Beobachtung aus einer unternehmenseigenen oder sonst primären Quelle ein Service-Operations-Problem relevanter machen könnte?“ Diese Frage hat Grenzen. Sie verlangt zuerst ICP-Fit, benennt den Quellenstandard und endet bei Review statt bei der Behauptung, das Unternehmen kaufe.
„Finde Intent-Signale“ ist dagegen keine Recherchefrage. Es lädt zu einer gemischten Liste aus Stellenanzeigen, Finanzierungsartikeln, Social Posts und allgemeinen Nachrichten ein; jedes Signal hat eine andere Bedeutung und Ablaufzeit. Das Ergebnis kann mit Score präzise wirken, obwohl Evidenz und Aktion unklar bleiben.
Schreibe den Trigger-Vertrag vor der Account-Sammlung:
Passt ein Satz nicht in eine dieser Zeilen, gehört er vermutlich in einen anderen Prozess: ICP-Qualifizierung, Kontakt-Research, Kampagnen-Review oder Customer Intelligence. Füge ihn nicht in den Trigger-Score ein, nur weil er interessant wirkt.
7. Spiele zwei Beispiele vollständig durch
Beispiel A: Eine Stellenanzeige ist Beobachtung, kein Implementierungsplan
Eine unternehmenseigene Karriereseite zeigt eine Rolle mit dem Titel „Field Service Systems Manager“ im Zielmarkt. Am Beobachtungsdatum darf das Protokoll sicher sagen: „Das Unternehmen listete diesen Titel auf seiner Karriereseite öffentlich.“ Es darf außerdem festhalten, dass die Anzeige relevant genug ist, um einen Account-Reviewer zu fragen, ob der Account in ein Service-Operations-Segment passt.
Es darf nicht sicher sagen, dass das Unternehmen Field-Service-Software kauft, ein freigegebenes Projekt oder Budget hat oder die Person in dieser Rolle Buyer ist. Die Stelle kann Ersatz, Spekulation, Fehler einer Drittplattform oder nur ein kleiner Teil einer großen Organisation sein. Dass sie von der Seite verschwindet, beweist nicht, dass die Initiative endete. Deshalb ist das Event ein zeitgebundener Research-Input, keine Kaufprognose.
Ein Review-Ergebnis kann lauten: Account erfüllt bereits ICP; Quelle ist aktuell; Rollenfamilie ist plausibel, aber nicht verifiziert; nächste erlaubte Aktion ist Recherche des operativen Kontexts. Es kann ebenso lauten: Account erfüllt ICP nicht; keine Priorisierung. Beide Ergebnisse stützen die Disziplin, weil das Event die Account-Regel nicht überstimmt.
Beispiel B: Eine Expansionsmeldung beweist kein lokales Problem
Eine offizielle Meldung sagt, ein Unternehmen habe in einem neuen Land ein Büro eröffnet. Das Protokoll darf Eröffnung, Quelldatum und Standort exakt wie veröffentlicht festhalten. Dein Team kann damit prüfen, ob Entität, Markt und Angebot relevant sind. Es darf daraus weder Headcount, Deployment-Bedarf, Beschaffungszeitplan noch eine freigegebene Kontaktaktion ableiten.
Kommt die Meldung von einer Muttergesellschaft, kläre zuerst, ob die genannte Entität der Account im Sheet ist. Bei Tochtergesellschaft, Niederlassung oder einem gleichnamigen anderen Unternehmen hältst du die Identitätsunsicherheit fest und enthälst dich, bis sie geklärt ist. Genau deshalb ersetzt Trigger-Research weder Marktkarte noch Entitätsauflösung.
Diese Beispiele sind bewusst begrenzt. Sie zeigen, wie du Beobachtung und zulässige interne Prioritätsentscheidung erhältst; sie schreiben nicht vor, was du einer Person sagst, und behaupten keine Fakten über reale Accounts.
8. Sammle Evidenz in wiederholbarer Reihenfolge
Folge für jeden ausgewählten Account derselben Reihenfolge, damit Reviewer die schwache Stelle finden:
- Bestätige Account-Kennung und ICP-Status vor dem Öffnen der Trigger-Quelle. Ein Signal ersetzt nicht die richtige Entität.
- Erfasse Original-URL, Seiten- oder Veröffentlichungstitel, Quellenklasse und Beobachtungsdatum. Verlasse dich nicht auf Vorschau eines Suchergebnisses oder eine Zusammenfassung ohne Link.
- Schreibe eine enge Beobachtung in Worten, die die Quelle selbst stützt. Zitiere nur das Notwendige für die interne Akte und verlinke den vollen Kontext.
- Schreibe die verlockende Schlussfolgerung in eine getrennte Spalte. Sichtbar notiert kann ein Reviewer unbelegte Personalisierung leichter zurückweisen.
- Wähle eine sichere nächste Aktion und eine Enthaltungsbedingung. „Account-Fit prüfen“ ist sicherer und besser testbar als „sofort kontaktieren“.
- Setze Review- oder Ablaufdatum. Ein altes Signal bleibt nicht unbegrenzt bestehen, nur weil es einmal einen nützlichen Account erzeugte.
Das Protokoll trägt diese Reihenfolge. Ein Leadbase-Research-Ergebnis kann für ein definiertes Feld ein hilfreicher Start sein, aber das Team muss weiter prüfen, ob Quelle und Zusammenfassung den Vertrag erfüllen. Confidence ersetzt weder Quellenrelevanz noch Entitätsauflösung oder freigegebene Entscheidung.
9. Entwirf einen fairen Pilot, bevor du ein Signal nützlich nennst
Wähle ein Segment, einen Beobachtungstyp, einen Quellenstandard und ein begrenztes Zeitfenster. Ziehe dann eine bewusst gemischte Stichprobe: Accounts mit aktueller qualifizierender Beobachtung, ohne diese Beobachtung, mit mehrdeutigen Quellen und mit bekannten False Positives wie falscher Entität oder abgelaufener Seite. Der Reviewer soll nicht nur die attraktiven Positivbeispiele sehen.
Bitte für jeden Stichproben-Account einen unabhängigen Reviewer, zulässige Aussage, Quellenzureichung, Account-Fit-Ergebnis und sichere nächste Aktion zu notieren. Vergleiche die triggergetriebene Priorität mit der Entscheidung nach normalem Account-Review. Das Pilot-Protokoll kann beispielsweise berechnen:
- Quellenzureichungsrate: Accounts, deren erhaltene Quelle den Vertrag erfüllte, geteilt durch geprüfte Accounts.
- Prioritätsänderungsrate: Accounts, deren Review-Priorität sich aus dem definierten Grund änderte, geteilt durch geprüfte Accounts.
- False-Priority-Rate: triggerpriorisierte Accounts, die später wegen Evidenz, Entität oder ICP-Grund abgelehnt wurden, geteilt durch triggerpriorisierte Accounts.
- Reviewer-Abweichungsrate: Datensätze, bei denen Reviewer bei der zulässigen Aussage abweichen, geteilt durch doppelt geprüfte Datensätze.
Keine dieser Kennzahlen misst Kaufabsicht oder Umsatz. Niedrige Quellenzureichung zeigt, dass Beobachtungsdefinition oder Quellenregel Arbeit brauchen. Hohe Abweichung zeigt eine zu lockere zulässige Aussage. Ein nützliches Ergebnis kann sein: „Nutze diesen Trigger nicht in diesem Segment.“ Das schützt vor einem überzeugenden, aber ungeprüften Score.
Halte den Nenner jeder Kennzahl im Protokoll fest
Verwende kontrollierte Werte, keine nachträglich rekonstruierten Notizen. Für die vier Kernkennzahlen berechnest du source_sufficient = yes geteilt durch Zeilen mit reviewed_at; eine Prioritätsänderung, wenn priority_after_review von priority_before_review abweicht, geteilt durch geprüfte Zeilen; spätere Ablehnungen mit later_rejection_reason unter anfangs als prioritised markierten Zeilen, geteilt durch anfangs priorisierte Zeilen; sowie reviewer_agreement = no geteilt durch Zeilen mit benanntem second_reviewer. Review-Zeit pro wirklich veränderter nächster Aktion ist die Summe von review_minutes für Zeilen mit next_action_changed = yes, geteilt durch die Anzahl derselben Zeilen; setze dieses Flag nur, wenn next_action_before_review und next_action_after_review abweichen. Nutze eine Prioritätsänderung nicht als Ersatz für eine veränderte Aktion. Leere, enthaltene oder ungeprüfte Zeilen bleiben im Protokoll, dürfen aber nicht still in einen Nenner geraten, dessen Status sie nicht erfüllen. Die herunterladbare Vorlage benennt diese Felder, damit ein anderer Reviewer die Raten reproduzieren kann.
Prüfe einen Trigger-Evidenz-Pilot
Übersetze einen Trigger-Evidenz-Pilot in prüfbare Raten mit expliziten Nennern für Quellen, Reviewer-Übereinstimmung, geänderte Aktionen und spätere Ablehnung.
Eine geänderte Priorität ist keine geänderte Aktion. Zähle eine Aktionsänderung nur, wenn sich die benannte Aktion vor und nach dem Review unterscheidet.
Unter 20 geprüften Zeilen haben 12 ausreichende Quellen und bei 4 ändert sich die benannte nächste Aktion. Die Reviewer-Übereinstimmung beträgt 80%; die spätere Ablehnung 25% der anfangs priorisierten Zeilen.
| Pilotrate | Ergebnis |
|---|---|
| Rate quellenausreichender Zeilen | 60% |
| Übereinstimmungsrate im zweiten Review | 80% |
| Rate geänderter benannter Aktionen | 20% |
| Rate späterer Ablehnungen | 25% |
| Review-Minuten je geänderter Aktion | 60 |
Vergleiche Evidenz- und Entscheidungsqualitätsraten, ohne sie als Kaufabsicht oder Umsatzwirkung umzubenennen.
Quellenausreichung und Aktionsänderung teilen durch alle geprüften Zeilen. Reviewer-Übereinstimmung teilt durch Zeilen mit zweitem Review. Spätere Ablehnung teilt durch anfangs priorisierte Zeilen. Review-Zeit je geänderter Aktion teilt gesamte Review-Minuten durch echte Änderungen der benannten Aktion.
Diese Kennzahlen prüfen, ob eine Beobachtung eine kontrollierte Rechercheentscheidung geändert hat. Sie messen weder Kaufabsicht noch Kausalität, Conversion, Pipeline oder Umsatz.
10. Entscheide, wann du dich enthältst oder einen Trigger einstellst
Lege Stop-Regeln neben Einschlussregeln. Enthalte dich, wenn ein Reviewer die Quelle nicht abrufen kann, Entität nicht aufgelöst ist, die Quelle außerhalb des Zeitfensters liegt oder die für die nächste Aktion erforderliche Aussage über die Quelle hinausgeht. Halte den Account, wenn Beobachtung interessant, aber steuernde Policy oder Account-Fit-Review offen ist. Stelle einen Trigger ein oder gestalte ihn neu, wenn der Pilot wiederholt mehrdeutige Evidenz, False-Priorities oder Aktionen erzeugt, die Empfänger nicht von unbelegten Outreach-Anweisungen unterscheiden können.
So entsteht eine glaubwürdigere Queue, als jedes öffentliche Event als Lead Score zu behandeln. Das Fehlen eines Triggers ist keine negative Evidenz über ein Unternehmen; es bedeutet nur, dass dieser Workflow gerade keinen vertragskonformen Grund zur weiteren Research-Priorität hat.
11. Trenne Trigger-Research von angrenzender Arbeit
Trigger-Research beantwortet, ob eine datierte Beobachtung einen begrenzten Review verdient. Es baut keine Marktkarte, etabliert keine Buying-Committee-Hypothese, verifiziert keine Person und bestimmt keine Compliance einer Nachricht. Schicke einen triggerpriorisierten Account erst durch diese relevanten Prozesse, wenn Evidenz und erlaubte nächste Aktion klar sind. Diese Trennung bewahrt den nützlichen Teil einer öffentlichen Beobachtung, ohne sie zu einer Behauptung aufzublasen, die Leadbase nicht macht: Echtzeit-Intent-Feed oder autonome Kaufprognose.
12. Prüfe die Sprache, die das Protokoll verlässt
Auch ein sorgfältiger Evidenzdatensatz kann scheitern, wenn seine Sprache für Queue, Briefing oder Nachricht verkürzt wird. Vergleiche eine Trigger-Notiz vor dem Teilen mit der zulässigen Aussage. Ersetze „expandiert schnell“ durch die exakt veröffentlichte Beobachtung; ersetze „braucht eine Lösung“ durch „kann Account-Review verdienen“; entferne eine Behauptung über eine benannte Person, wenn sie kein eigener Personen-Research-Datensatz stützt. Kann eine Kurzfassung die Grenze nicht erhalten, behalte den Quellenlink und nutze die Kurzform nicht als Behauptung.
Setze bei wirkungsstarken oder mehrdeutigen Events einen zweiten Reviewer ein. Diese Person muss nicht zustimmen, dass der Account attraktiv ist. Sie muss zustimmen, dass der Datensatz nicht mehr sagt als die Quelle stützt und die vorgeschlagene nächste Aktion auch bei falscher Hypothese sicher ist. Abweichung ist nützliche Evidenz dafür, dass Triggerdefinition, zulässige Aussage oder Enthaltungsregel enger werden müssen.
Prüfe die Quelle unmittelbar vor der Nutzung noch einmal
Bei einem zeitkritischen Trigger prüfst du die erhaltene Quelle unmittelbar vor der Nutzung des Datensatzes im Prioritäts-Review noch einmal. Halte fest, ob die Seite weiter verfügbar ist und ihre wesentliche Aussage unverändert ist. Das ist keine Behauptung über Echtzeit-Monitoring, sondern eine bewusste Reviewer-Aktion für die kleine Zahl von Accounts, deren nächste Aktion von Aktualität abhängt. Ist die Quelle verschwunden, wesentlich verändert oder nicht prüfbar, wendest du die Veraltungs- oder Enthaltungsregel des Vertrags an. Ersetze diese Unsicherheit nicht durch eine stärkere Zusammenfassung, nur weil ein früherer Lauf die Seite fand.
13. Vergleiche keine unterschiedlichen Events unter derselben Zahl
Ein Job Posting, ein Registereintrag und eine Expansionsmeldung können alle zu einer Prioritätsqueue führen. Sie dürfen dennoch nicht blind unter einem „Intent-Score“ addiert werden. Sie stammen aus unterschiedlichen Quellenklassen, haben unterschiedliche Ablaufregeln und stützen unterschiedliche Aussagen. Ein höherer Score kann sonst nur bedeuten, dass ein Account mehr öffentliche Erwähnungen hat, nicht dass eine konkrete kaufrelevante Hypothese besser belegt ist.
Wenn dein Team mehrere Eventtypen prüft, gib jedem einen eigenen Vertrag, Quellenstandard und Pilot-Auswertung. Vergleiche dann nicht vermeintliche Nachfrage, sondern praktische Eigenschaften: Wie oft war die Quelle ausreichend? Wie häufig änderte sie nach Account-Review wirklich die Priorität? Wie viele Fälle waren wegen Entität, Ablauf oder fehlender Evidenz nicht verwendbar? Erst wenn diese Fragen sauber beantwortet sind, kann ein Team entscheiden, ob zwei Eventtypen dieselbe begrenzte Review-Aktion auslösen dürfen.
14. Behandle Zeit als Eigenschaft der Behauptung
Bei Triggern ist das Beobachtungsdatum nicht Dekoration. „Das Unternehmen listete am 8. August eine Rolle“ und „das Unternehmen sucht diese Rolle“ sind unterschiedliche Aussagen. Die erste bindet sich an die Quelle und das Datum; die zweite suggeriert Gegenwart, die nach dem Ablauffenster nicht mehr gesichert ist. Formuliere deshalb die Aussage im Protokoll so, dass ihr Zeitpunkt sichtbar bleibt, und setze eine Regel, wann sie nicht mehr als Prioritätsgrund dient.
Das bedeutet nicht, dass alle Quellen den gleichen kurzen Ablauf bekommen müssen. Ein offizieller Registereintrag kann für eine andere Frage und länger relevant sein als eine Karriereseite. Entscheidend ist, dass die Ablaufgrenze aus der erlaubten Aktion folgt. Soll die Beobachtung lediglich eine spätere Marktkarte ergänzen, kann eine andere Regel gelten als für einen Review in dieser Woche. Übernimm keine pauschale Tageszahl ohne diesen Zusammenhang.
15. Verhindere Feedback-Schleifen, die den Trigger nachträglich bestätigen
Eine gefährliche Auswertung sieht so aus: Ein Account mit Trigger erhält mehr Aufmerksamkeit, bekommt eine bessere Research-Notiz und wird dann als Beweis gezählt, dass der Trigger funktionierte. Das verwechselt zusätzlichen Aufwand mit Signalwert. Nutze deshalb eine Vergleichsgruppe ohne Trigger und dokumentiere bei allen Gruppen dieselbe Account-Review-Tiefe. Wenn nur die Triggergruppe intensiv geprüft wird, sagt eine höhere Zahl gefundener Zusammenhänge nichts darüber aus, ob das ursprüngliche Event eine sinnvolle Priorität war.
Dokumentiere außerdem, wenn ein Reviewer die ursprüngliche Beobachtung erst nachträglich umdeutet. Eine Erweiterung von „Rolle war ausgeschrieben“ zu „Team modernisiert seine Prozesse“ ist eine neue Hypothese und braucht eigene Evidenz. Sie darf nicht rückwirkend den ursprünglichen Trigger als stärker erscheinen lassen. Ein sauberer Pilot erhält die erste zulässige Aussage und trennt spätere Entdeckungen davon.
16. Lege eine kleine Trigger-Bibliothek mit Entscheidungen an
Nach einem Pilot brauchst du keine große Sammlung von Signalnamen. Lege lieber eine knappe Bibliothek an, in der für jeden getesteten Trigger seine Population, zulässige Beobachtung, Quellenklasse, Ablauf, sichere Aktion, Stop-Regel und Pilotentscheidung steht. Zum Beispiel: „Karriereseite mit definierter Operations-Rolle — nur für bereits qualifizierte Accounts — Account-Review priorisieren — keine Purchase- oder Buyer-Behauptung — erneute Prüfung vor nächster Nutzung.“
Ergänze auch abgelehnte Trigger. Ein verworfener Eventtyp, dessen Quellen oft nicht erreichbar waren oder dessen Reviewer stark abwichen, schützt das Team vor späterem Wiederholen derselben scheinbar neuen Idee. Die Bibliothek ist kein proprietärer Intent-Feed und keine globale Marktbehauptung. Sie ist das nachvollziehbare Gedächtnis deiner eigenen Tests und Entscheidungen.
Mache dein eigenes Signal ausführbar
Vordefinierte Intent-Produkte ordnen Ereignisse in die Taxonomie und das Scoring-Modell des Anbieters ein. Leadbase unterstützt eine andere Aufgabe: Nimm die konkrete öffentliche Veränderung, die für dein Team zählt, mache daraus ein fokussiertes Recherchefeld und halte Beobachtung, Quelle, Datum, Confidence-Signal, Review-Entscheidung und nächste Aktion zusammen.
Dein Signal muss nicht in der Taxonomie eines Anbieters existieren. Es braucht eine präzise Beobachtungsregel und eine sichere Aktion für den Fall, dass die Hypothese falsch ist.
Genau das macht das eigene Signal nutzbar. Eine Karriereseite, Expansionsmeldung oder ein anderes öffentliches Ereignis wird nicht zu „Intent“, weil ein Modell es gefunden hat. Es wird zu einem prüfbaren Input, weil dein Team die Quelle kontrolliert, Beobachtung und Schlussfolgerung trennt, Konflikt oder No-Result sichtbar lässt und misst, ob sich Priorität oder Aktion tatsächlich verändert haben.
Leadbase ist kein proprietäres Intent-Data-Produkt, kein Echtzeit-Event-Monitoring und keine automatische Scoring-Engine. Für eigene Fragen bietet es etwas Kontrollierbareres: Deine quellenverlinkte Hypothese erhält einen strukturierten Ort, an dem sie für ausgewählte Accounts laufen und im Review angegriffen werden kann. Erstelle einen Trigger-Evidenz-Pilot und entscheide zuerst, ob das Signal überhaupt bestehen sollte.
Checkliste zur Triggerfreigabe
- Quelle stützt die enge Beobachtung direkt oder als originalgetreue Zusammenfassung.
- Zulässige Aussage und ungestützte Schlussfolgerung stehen getrennt.
- Aktualitäts- und Enthaltungsregeln stehen vor dem Review fest.
- Die Aktion ist sicher, wenn die Hypothese falsch ist.
- Eine Kontrollstichprobe prüft False Priorities.
- Kampagnenzulässigkeit wird nicht aus dem Event abgeleitet.
