Did an Amperity_ID Ever Exist? Understanding Missing, Merged, and Erased IDs

Sometimes you may need to confirm whether an Amperity_ID ever existed in your tenant, determine whether it was merged into another identity, or understand why it no longer appears in unified or transactional data. This article explains how Amperity handles historical identities, merges, and privacy erasures, and what it means when an Amperity_ID can no longer be found.

What You Might See

You may search for a specific Amperity_ID and find:

  • No results in unified_customer, unified_coalesced, unified_itemized_transactions, or Unified_Changes
  • A downstream system indicates an AmpID “changed” to a new one
  • The old AmpID is missing entirely from production

This can raise questions about whether the ID was merged, deleted, erased, or if it ever existed in production at all.

 

How Amperity Handles Identity History

If an ID Was Merged or Joined

When two identities are stitched together:

  • A new or surviving Amperity_ID becomes the active ID
  • The original Amperity_ID is not deleted
  • A persistent merge record is written to Stitch history tables

You can see this in:

  • Unified_Changes_PK
  • Unified_Changes_Clusters

It appears as amperity_id_prev, showing which ID was merged into which. This history is only retained for the configured Stitch retention window (commonly ~30 days). After that window, merge history is no longer queryable.

 

If a GDPR/CCPA Erasure Occurred

This behaves very differently:

  • The Amperity_ID is fully removed
  • Data is deleted across unified, coalesced, and itemized tables
  • No amperity_id_prev records remain
  • Amperity does not maintain a “master list” of erased IDs for privacy compliance

This results in the identity appearing as if it never existed.

 

If the ID Only Ever Existed in a Sandbox

If an identity was created in a sandbox that was later deleted:

  • It will not appear in production
  • It will not appear in Stitch history
  • It will have no records in unified or transactional tables
  • Support cannot query deleted or decommissioned sandboxes

This can create a similar “never existed” pattern.

 

What an Empty amperity_id_prev Means

If amperity_id_prev is blank for a Unified_Changes row:

  • The change event did not come from a merge
  • There was no previously tracked Amperity_ID for that event
  • It does not indicate a merge relationship

Summary

ScenarioWhat HappensCan You Trace It?
Merge / JoinOld ID retired, new ID activeYes, within Stitch history window
GDPR / CCPA ErasureID completely removedNo
Sandbox-only identityNever existed in productionNo
Blank amperity_id_prevNot a merge eventMeaning = “no previous ID recorded”

 

If You Need to Investigate

To research an identity, check:

  • unified_customer
  • unified_coalesced
  • Unified_Changes_PK
  • Unified_Changes_Clusters

If nothing exists anywhere and the ID cannot be found, it is most commonly due to:

  1. Privacy erasure, or
  2. Data existing only in a sandbox or prior environment outside current retention history