How does Ometria subscribe and unsubscribe contacts?

Ometria uses hierarchies when determining whether a contact’s subscription status should be changed or not, depending on where the subscription event came from.

Ometria is dedicated to protecting the validity of subscription events, and ensuring that they cannot be overridden by mistake.

See also:

• Campaign performance: Subscribers report
• Retrieve contacts that unsubscribed using their email client (via API)

Hierarchy

@FORCE_OPTIN=TRUE

This is an Ometria field that is passed from forms that include Ometria code, such as:

• an Ometria preference centre 
• via API
• via CSV upload. 

@FORCE_OPTIN=TRUE is used to force the marketing_optin value passed (whether the event is a subscribe or an unsubscribe) in the same contact record.

When @force_optin is set to 'TRUE', this event takes precedence as the default marketing opt-in priority.

In this example, the contact is being force opted-in to receive marketing communications:

“@force_optin"= true,
"marketing_optin"= "EXPLICITLY_OPTEDIN"

And in this example, the contact is being force opted-out of marketing communications:

"@force_optin": true,
"marketing_optin": "EXPLICITLY_OPTEDOUT"

This action is added as a top-level parameter on the contact record and only needs to be sent once to perform the action.

@FORCE_OPTIN cannot be overridden by a ‘non-forced’ update (e.g. from third party platforms), meaning in some cases a subscribe event from an eCommerce platform - e.g. the contact leaves a ‘subscribe me’ checkbox selected on check out - might not be applied to the customer due to an existing @FORCE_OPTIN=true unsubscribe event. 

The only way this type of subscription event can be overridden is via another Ometria @FORCE_OPTIN=true event - for example by updating the preference centre.

Other methods

If there is no @FORCE_OPTIN=true field passed, then the following order of precedence is used:

1. Preferences centre.
2. Ometria API, in-app change, CSV upload - these methods all have equal weight, and can override each other.
3. Form
4. Importer (e.g. Magento, Shopify)
5. Third party

Subscription events and timestamps

Ometria only generates events (e.g. to trigger a campaign) the first time a contact is subscribed and the first time a contact is unsubscribed. 

This is to prevent a welcome campaign being sent a second time, when the contact might already be a customer. 

Ometria can only generate an event if a timestamp_subscribed field is supplied, as this determines the date and time of subscription to trigger the welcome campaign.

Timestamp discrepancies

Sometimes anomalies can occur; for example, a contact can be marked as unsubscribed, with a date of unsubscribing six months ago, but still have a more recent subscribed date.

If someone re-subscribes (e.g. at checkout) or by updating their preferences, although Ometria doesn’t trigger another event, the contact’s timestamp record is updated, whether the subscribe action was successful or not (depending on the hierarchy above). 

This means it is possible for timestamps and subscription status’ to appear out of sync when checking a contact profile on Ometria.