Data quality and troubleshooting
Why are my events rejected?
The collector response states a status per event and, on failure, the reason. Check that response first; “Data status” in the portal additionally summarises the reasons over the period.
The collector does not accept events. How do I find the cause?
{
"received": 3,
"accepted": 1,
"duplicates": 1,
"rejected": 1,
"blocked": 0,
"results": [
{ "eventId": "a", "status": "accepted" },
{ "eventId": "b", "status": "duplicate" },
{ "eventId": "c", "status": "rejected", "code": "SCHEMA_INVALID" }
]
}| Counter | Meaning |
|---|---|
| accepted | stored and queued for processing |
| duplicates | the event ID was already known; not counted twice |
| rejected | formally or substantively invalid; the code names the reason |
| blocked | nothing stored because consent is missing or withdrawn, the person is on the suppression list, the quota is used up or there were too many requests; the code names the reason |
Note
One invalid event never discards the whole batch. Always check the individual results, not just the HTTP status.
In the portal, rejections appear under “Data status → Data content”: as a count for the period (“Invalid format”) and as one finding per reason with its error code. They are something different from events that were accepted and only failed during processing. Those are listed under “Processing”.
We do not store the content of a rejected event. We keep the reason, time, source, website, event type and the affected fields with the type and length of the value, but never the value itself. The finding in the portal names these fields, for example “page_url” or “metadata.contact”. What exactly you sent appears only in the collector’s response to your system.
Note
For PII_DETECTED this applies without exception: the email address or phone number that caused the rejection ends up neither in the raw data nor in the error log. If a key in metadata itself looks like an address, it shows as “[masked]”.
Last reviewed on 12 Oct 2026
Also asked
- Rejected events
- Events not arriving
- Why is my event discarded?
- Does Metrunio store rejected events?
- What is kept in the error log?
- Which field contains the email address?
Related articles
- What do the error codes mean?
The collector answers with a code. What does it mean?
Every rejection carries a code together with a title, explanation, data effect and resolution steps. This table lists all codes of the collector and of processing with their meaning.
- Which events does Metrunio measure?
Which event types exist and what consent do they need?
There are fifteen event types. The four advertising events require marketing consent, all others at least analytics consent; without matching consent an event is not stored. The only exception is purchases and refunds your server reports without consent: they count for revenue reconciliation with their order number, without browser, customer or advertising identifiers, and are not attributed; after a refusal this only applies with an activated additional instruction.
- Which data is stored?
What exactly does Metrunio hold about my website’s visitors?
Pseudonymous identifiers, event data with timestamps, campaign and click identifiers, and conversion values. No raw IP addresses; event fields are not meant to hold plain-text names or contact details. Detected email addresses and phone numbers cause rejection; the automatic check does not detect every kind of personal data, though.
- What does a processing backlog mean?
Events have arrived but journeys are not appearing. Why?
A queue sits between reception and reporting. When it grows faster than it is worked off, a backlog forms: raw events are already there, journeys and conversions are not yet. If processing an event fails for good, the portal reports it as FAILED_JOBS for seven days; support can replay it.