Databases
Product Analytics Destination Cleanup: Remove Unused Forwarding Targets
Product analytics pipelines often forward the same event stream to many destinations: warehouses, ad platforms, support tools, lifecycle email systems, feature flag platforms, and customer success dashboards. After teams change tools, the forwarding target may keep receiving events even though nobody uses the data. That creates cost, privacy risk, and confusion about which destination is authoritative.
Cleanup should remove unused destinations only after owners confirm the downstream job is gone.
Map the destination’s real consumers
For each destination, capture event types, filtered properties, last delivery, failure rate, owning team, downstream dashboards, and contracts.
| Destination clue | Evidence to inspect | Cleanup concern |
|---|---|---|
| No dashboard reads | BI usage and saved reports | Data may still feed exports or reverse ETL |
| Low event volume | Segment filters and product traffic | Niche events may be customer-critical |
| Old vendor name | Tool migration notes and contracts | Legal or billing commitments may remain |
| High failure rate | Retry queues and dead letters | Destination may be broken but still expected |
| PII fields | Data map and retention policy | Cleanup may reduce privacy exposure |
A useful review query is about downstream use:
SELECT destination_name, event_name, COUNT(*) AS delivered_events
FROM analytics_delivery_audit
WHERE delivered_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY destination_name, event_name
ORDER BY delivered_events DESC;This shows delivery volume. It does not prove anyone reads or needs the delivered data.
Do not rush these destinations
Slow down when a destination feeds revenue attribution, customer health, support context, compliance reporting, or lifecycle messaging. Also slow down when the destination is used by a non-engineering team that may not watch pipeline alerts.
Retire in a visible sequence
First, identify data owners and downstream consumers. Second, turn off event types or properties in a narrow scope before removing the destination entirely. Third, monitor delivery failures, support tickets, and stakeholder dashboards during the waiting window. Fourth, remove credentials, webhooks, and vendor-side mappings after forwarding stops.
If the destination remains, document why. “Customer success still reads account activation events weekly” is a useful reason; “old tool” is not.
Prevent forwarding sprawl
New analytics destinations should require an owner, purpose, event list, privacy review, and review date. Tool migrations should include old destination cleanup alongside new destination validation. Event catalog entries should show where each event is forwarded so cleanup does not require tracing hidden vendor settings.
Key takeaways
- Analytics destination cleanup reduces cost, privacy exposure, and metric confusion.
- Delivery volume is not the same as business use.
- Remove event types or properties before deleting critical destinations.
- New forwarding targets need owners, event lists, and review dates.