## TL;DR
When Segment Protocols blocks an event, the event usually arrived fine and was then discarded for breaking the tracking plan, so debugging the app code wastes the day. Open the violation record for subscription_cancelled, read the exact rule it broke, then fix the side that is wrong, the event payload or the plan itself, and replay from the billing source for the blocked window. Never just switch blocking off without knowing which events it has been eating.

```text
Segment tracking plan violation blocked the subscription_cancelled event: churn signal never reached the warehouse
```

## Use this when
- Segment shows tracking plan violations naming subscription_cancelled
- The event is visible in the Segment debugger but absent in the warehouse
- Protocols is set to block or drop violating events for this source

## Not for this skill when
- The debugger shows no event at all for a test cancellation, which is an instrumentation problem
- The warehouse destination itself is failing for all events, not only violating ones

## Steps
1. Fire a controlled test cancellation and watch it in the Segment debugger for the production source, capturing the full payload exactly as sent including property names, types, and context fields. You need the real payload, not the intended schema from a spec document, because violations live in the difference between the two. Verify: the captured payload is saved with the test event and its timestamp
2. Open Protocols, select the tracking plan attached to that source, and open the violations view filtered to subscription_cancelled. Read the specific violations, such as an unplanned event, a required property missing, or a property sent as a string where the plan demands a number, and note the first violation date to size the data loss window. Verify: each violation is listed with its rule, and the first blocked date is known
3. Decide per violation which side is authoritative. If the plan is right, the emitting service must send the required property with the right type. If the product legitimately changed, for example cancellation now carries a reason code the plan never listed, update the plan through review instead of forcing the code back. Record the decision in the tracking plan change notes. Verify: every violation has an owner and a fix side, code or plan, written down
4. Apply the fix and send another test cancellation through the debugger, confirming Protocols now passes it and the event lands in the warehouse table with the account id, plan id, and cancellation timestamp intact. Check the warehouse row, not only the Segment UI, because the original symptom was a warehouse gap. Verify: the test event passes Protocols and its warehouse row is queryable
5. Measure and repair the blocked window. Count true cancellations in the billing system between the first violation date and the fix, load them into the churn pipeline with their original timestamps, and flag the Segment-sourced rows for that window as incomplete so nobody double counts the backfill. Verify: billing and warehouse cancellation counts agree for the window within an agreed tolerance
6. Tighten the process so this cannot recur silently. Add a daily violations alert routed to the data owner, require tracking plan review for lifecycle event changes, and keep blocking enabled only for sources where a named owner watches violations every day. Verify: a violations alert exists and a test violation reaches the owner

## Why it happens
Protocols enforces the tracking plan at ingestion and, in blocking mode, discards non-conforming events before any destination sees them. The warehouse therefore shows a clean absence rather than an error, and the churn pipeline, which trusts the warehouse, reports fewer cancellations with total confidence. The enforcement is doing its job, the failure is that a load-bearing lifecycle event and the plan drifted apart with no alert on the violation stream.

Compatibility: Segment Protocols tracking plans, source debugger, and warehouse destinations such as Snowflake or BigQuery, in current Segment workspaces.

## Variants and edge cases
### Segment Protocols blocking event warehouse missing
['The warehouse-first phrasing. If the debugger shows the event and the warehouse does not, Protocols and destination filters are the two suspects, and the violations view decides between them in minutes.']

### subscription_cancelled unplanned event violation
['The unplanned-event variant, common after a new billing service starts emitting lifecycle events before the plan is updated. Add the event to the plan deliberately with its full property schema.']

### Segment tracking plan property type violation fix
['The type-mismatch variant. JSON numbers sent as strings are the classic case from form and webhook relays, so inspect any middleware that re-serialises the payload between the app and Segment.']

Edge cases to work through before you close the incident:
- Blocking mode, omitting mode, and warning mode behave very differently. Confirm the actual setting per source, because a plan can block on the server source while only warning on the web source.
- A destination can also have its own event filter allowing only listed events. If Protocols passes the test event but the warehouse still misses it, check destination filters next.
- Do not backfill by re-sending events through Segment with todays timestamps. Load history directly to the warehouse with original timestamps or every time-based churn model shifts.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Q4SVm3uSwLgvVu6Hhu6fMQ