Tracking plan
Nedir Tracking plan?
Bu terim şu anda yalnızca İngilizce olarak sunulmaktadır.
A tracking plan is the tenant-owned CDP event contract: the canonical map of event names and property types each event may carry. The destination catalog and the CDP event-ingest endpoint validate incoming events against it, so a producer sending an unknown event name or a mistyped property gets a tracking-plan violation instead of silently corrupt data. It is narrower than a generic schema registry: it governs the event contract, not every payload shape.
More detail
Author the plan in the dashboard under Integrations → CDP: each event row declares the property names, their types, any enum values, whether a property is required, and the enforcement level for that event.
Enforcement is per event. In soft mode a mismatch is accepted and logged, so SDK drift stays visible without losing events. In strict mode the ingest endpoint rejects the event with 422 TRACKING_PLAN_VIOLATION, and the error body names the rule that fired — a missing required property, a type mismatch, a value outside the declared enum, or an undeclared extra property.
Recovery runs through the dashboard's per-event violations feed (Integrations → CDP → Tracking Plan → Violations): decide between fixing the producer to match the plan, amending the plan to legitimize the new shape, or dropping the event from strict back to soft while an unforce-updateable producer catches up.
Sık sorulan sorular
- How is a tracking plan different from a schema registry?
- A schema registry is a generic store of payload shapes. A tracking plan is the CDP-specific event contract: it maps event names to the properties and types those events may carry, it is owned per tenant, and the event-ingest endpoint enforces it directly — with a per-event soft/strict enforcement switch a generic registry does not carry.
- What is a tracking-plan violation?
- The rejection a signed CDP event ingest returns (422 TRACKING_PLAN_VIOLATION) when an incoming event's name or a property's type diverges from the plan you authored in strict mode. The error body lists each broken rule — missing required property, type mismatch, enum mismatch, extra property, or unknown event — along with the expected shape and the value that arrived.
- Should a new event start in soft or strict mode?
- Soft. Unknown events are recorded and accepted, which lets a new producer version roll out without data loss while the violations feed shows the drift; flip the event to strict once its real-world traffic matches the plan row you intend to enforce.
- Where do I see the events my plan rejected?
- Open Integrations → CDP → Tracking Plan → Violations in the dashboard — the per-event violations feed carries the same rule rows the 422 error body returns, queryable per event name and enforcement level.
See also
Build it on Orbit
Voice, messaging, email, video, and AI agents on one platform and one pay-as-you-go bill. Start free — no credit card required.