Event Delete & Update lets you correct event data after it has been ingested. You can remove an event that should not exist, or update parameters for an event that exists but contains outdated information. Every change is applied through the Insider One APIs and automatically reflected in segments, journeys, and analytics.
Delete vs. Update
Both operations target a single event on a single user profile. The choice depends on whether the event should exist at all.
Delete
The event should not exist:
A duplicate event was sent for the same order or transaction
A test or smoke-test event landed on a production user profile
A transaction was fully reversed by the bank
An event was sent in error and has no real-world counterpart
Update
The event is real, but its parameters are outdated:
A customer changed a booking, subscription plan, or order after the event was recorded
A partial refund changed the amount on a purchase or transaction event
A promo code, plan flag, or status field no longer reflects the current state
A billing cycle or travel class was changed after activation
How Event Delete & Update works
API only
Every delete and update is sent as an authenticated POST request to the Insider Unification APIs. There is no panel UI for this operation.
One event, one user
Each request targets exactly one event on one user profile. To correct multiple events, send multiple requests. Bulk operations are not supported.
Unique identification required
You identify the target event by combining a user identifier with an event-level identifier — a precise timestamp, a set of parameter filters such as order_id or transaction_id, or both. If the combination matches more than one event, the request is rejected.
Automatic recalculation
After a delete or update is applied, segments, journeys, and analytics are automatically re-evaluated against the corrected event data. No manual trigger is required.
Rejected requests:
If the identifier combination you provide matches more than one event, the request is rejected and no change is applied. Use a more specific identifier, such as a business key like order_id combined with a timestamp, to ensure the request targets exactly one event.
Use cases by vertical
The examples below show how teams across different industries use Event Delete & Update to keep behavioral event data accurate.
Ecommerce: Return or partial refund
Scenario: A purchase event was recorded when the customer bought 3 items. The customer later returned 1 item. The original event no longer reflects the actual order, distorting revenue metrics and re-engagement journeys.
Example operations
Update total_price and item_count after a partial return
Change order_status from completed to partially_returned
Remove a returned SKU from the order's product list
Travel: Destination or booking change
Scenario: A booking_completed event was saved with destination = "Paris", but the customer changed the trip to London. Pre-trip campaigns are now targeting the wrong city.
Example operations
Update destination, total_price, or currency after a trip change
Update travel_class after an upgrade
Remove a promo_code that no longer applies to the new booking
Subscription: Plan change after activation
Scenario: A subscription_start event was saved when the customer signed up for the standard plan. The customer upgraded to premium before activation. Tier-based segments and renewal journeys still reflect the old plan.
Example operations
Update plan_name and monthly_price after an upgrade or downgrade
Update billing_cycle when the customer switches from monthly to annual
Remove a trial flag once the trial converts to a paid subscription
Fintech: Refund or transaction reversal
Scenario: A transaction event was saved with the original purchase amount. The customer later received a partial refund, or the bank reversed the transaction in full, and the event should be removed from the user's history entirely.
Example operations
Update transaction_amount after a partial refund
Change transaction_status from completed to refunded
Delete the transaction event when the bank reverses it in full
Use transaction_id to identify the exact event instance
QA & testing: Test events on production profiles
Scenario: A QA pipeline fired test events into production using real customer identifiers. Those events are now present in real user histories, affecting segmentation and analytics.
Example operations
Delete test purchase or signup events using their timestamp or test_run_id
Remove smoke-test events fired during a release window
Clean up without deleting and re-creating the user profile
Next step:
See Create an Event Delete or Update Request for the full API reference, required parameters, and sample requests for each operation type.