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.

Hierarchy

@FORCE_OPTIN=TRUE

This is an Ometria field that is passed from forms that include Ometria code, such as a preference centre hosted on Ometria, or via API or CSV upload. 

@FORCE_OPTIN=TRUE is used to force the marketing_optin value passed in the same contact record. When @force_optin is set to 'TRUE', this will take 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"

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 6 months ago, but still have a more recent subscribed date.

If someone re-subscribes (for example 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.