Field-forget lets a retailer null a specific contact's email address and/or phone number through the Ometria API, without deleting the contact record itself. It's a separate feature from GDPR anonymisation, and the two work differently enough that it's worth knowing which one a retailer actually needs.
How it's different from anonymising a contact
Anonymising a contact satisfies a GDPR erasure request: it hashes the contact's identifying fields and blocks new data from re-identifying them unless they explicitly opt back in.
Field-forget is narrower and reversible in a different way:
- It clears one field at a time (email, phone, or both in one request), not the whole contact.
- The contact record stays active and keeps sending to other channels.
- The cleared value is deleted, not hashed, so it's immediately free to reuse. If a retailer pushes an update giving that same email address to a different contact, it's accepted straight away.
- There's no re-optin flow to walk through, because nothing was blocked. A later contact update that sets the value again just restores it.
Don't suggest anonymise as a fallback when a field-forget request is refused. The two aren't interchangeable, and the refusal (below) already reflects a deliberate rule, not a technical failure.
Finding a contact's profile hash
Field-forget identifies a contact by profile_hash, an opaque string unique to that contact (format like 2c1d-abc123-00000042). It's the same identifier used in the contact's preference-centre link and the merge-profile endpoint.
Retailers and support can both find it on the Single Customer View profile page, next to the contact's email and customer ID, with a copy-to-clipboard button. Support can also read it from the admin profile-debugger if needed.
What happens when a field is cleared
Clearing email: removes the email address from the contact, deletes the email identifier, and unsubscribes the contact from the email channel (since there's no address left to send to).
Clearing phone: removes the phone number from the contact, deletes the phone identifier, and unsubscribes the contact from SMS.
Either way, the field is also cleared from the contact's stored attributes and from any store-level listings for that contact, so it doesn't resurface somewhere else in the platform.
💡 This is one-shot. A later contact update from the retailer's feed that sends the value again restores it, exactly like adding any other field.
When a request is refused
A request to clear email is refused if the contact has no other identifier (no customer ID on file). Clearing it would leave the retailer with no way to recognise that contact at all, so Ometria abandons the request rather than doing this.
Be aware: the refusal doesn't say more than that a matching identifier would no longer remain. It's a terminal outcome, not a temporary failure, so there's nothing to retry. If a retailer wants that contact's email cleared, they need a customer ID on the record first.
Clearing phone doesn't carry this restriction.
Checking the status of a request
A field-forget request is asynchronous: submitting it returns an in-progress reference, and it reaches a final status (completed, refused, or failed) shortly after.
Today, you can see status two ways:
- On the contact's Single Customer View timeline, alongside their other activity.
- Through the API's own status endpoint, which is what most retailers use since field-forget is currently API-only.
There's no console admin screen listing an account's field-forget requests yet, so if a retailer can't locate a contact to check the SCV timeline (for example the request targeted the wrong profile_hash), you won't be able to look it up independently. Escalate to engineering in that case.
Comments
0 comments
Article is closed for comments.