Event validation rules — Docs

Hardere garanties dan 'het event vuurt': bewaak dat purchase altijd value + currency + transaction_id heeft.

Een purchase-event dat vuurt zonder value is erger dan een event dat helemaal niet vuurt: GA4 registreert het als conversie, maar revenue-rapporten zijn incompleet. Attribution-modellen krijgen niet-matchende signalen. En je merkt het pas weken later als iemand Looker Studio opendoet.

Validation rules zijn schema-checks per event-type. Als een rule faalt, log je een violation — en Signum alert je meteen, niet 3 weken later.

Standaard rules (auto-aan)

Bij elke klant staan 4 rules default aan — gebaseerd op GA4's eigen schema + Google Ads-vereisten:

purchase → MUST have value (numeric, >0), currency (3-letter ISO), transaction_id (unieke string)
generate_lead → MUST have value (numeric, currency (ISO). Enhanced Conversions: plus user_data.email_hashed.
form_submit → MUST have form_id (string, niet leeg).
add_to_cart → MUST have items[] (niet-lege array), elk item MUST have item_id.

Violations triggeren alerts met severity warn standaard. Je kunt per rule escaleren naar critical (direct Slack-ping) voor kern-events.

Custom rules toevoegen

Dashboard → klant → Validation rules → + Nieuwe rule. Of via API:

POST /monitoring/validation-rules
{
  "clientId": "sc_c_xxxx",
  "eventName": "subscription_start",
  "severity": "critical",
  "required": [
    { "path": "plan_name", "type": "string", "notEmpty": true },
    { "path": "value", "type": "number", "min": 0 },
    { "path": "currency", "type": "string", "match": "^[A-Z]{3}$" }
  ],
  "conditional": [
    {
      "if": { "path": "trial_duration_days", "exists": true },
      "then": { "path": "trial_duration_days", "type": "number", "min": 1 }
    }
  ]
}

Type-checks die je kunt gebruiken

string — optioneel notEmpty, match (regex), enum
number — optioneel min, max, integer
array — optioneel minLength, itemSchema (recursief)
object — optioneel properties (nested required)

Hoe validation draait

Bij elk event-binnenkomst (via RUM-beacon, via GA4 Measurement Protocol-mirror, of via server-side dataLayer):

Event wordt gematcht op eventName tegen alle actieve rules voor die klant
Per gematchte rule: iedere required/conditional check
Violations worden per rule geaggregeerd in een 15-min-window
Bij >5 violations in 15 min (of direct bij 1 critical violation): alert via geconfigureerde kanalen

Violations bekijken

Dashboard → klant → Validations-tab. Filters:

Per event-type — zie in 1 oogopslag welke events meeste problemen geven
Per severity — critical staan altijd bovenaan
Per time-range — 24u / 7d / 30d / custom

Elke violation toont: event-payload, welke rule faalde, welke check specifiek (bv. value missing), en user-agent + source (handig voor reproductie).

Common patterns

1. E-commerce met refunds

refund events MUST have transaction_id die matcht met eerder gezien purchase. Zonder match = waarschijnlijk een buggy integratie of een refund zonder originele purchase (fraude-flag?).

2. Lead-gen met kwaliteitsscore

generate_lead MUST have lead_score of expliciet lead_score: null. Dwingt dev-team om scoring-logica te implementeren — geen leads zonder context.

3. SaaS trial-funnel

trial_start MUST have plan_name enum [starter, agency]. Als er "small" binnenkomt: rule faalt, alert, je weet dat een rename in de app niet in tracking is doorgevoerd.

Te agressieve rules = alert-fatigue. Begin met 2-3 kritieke events (purchase, generate_lead) op severity critical. Voeg custom rules pas toe als je een concrete miss hebt gehad.

Rules uitzetten tijdens deploys

Bij een geplande site-change (zie site-change workflow) kun je rules tijdelijk op warn-only zetten zodat je niet overstroomd wordt met alerts tijdens een bekende breuk. Setup via PATCH /monitoring/validation-rules/:id met pausedUntil: ISO-date.