Conventions


Store IDs


The store identifier (used in orders and in the javascript tracking layer) can be any string value. We recommend the use of the sites domain name (e.g. example.com). If your store has variable 'sub-stores' (e.g. different territories) we recommend the naming convention <domain>/<language> (e.g. example.com/uk).

It is also acceptable to use numeric store IDs if you have these defined, e.g. "123".


Products v Product variants


Typically, a parent product in Ometria corresponds to a single product page on the e-commerce store. A product may have multiple variant SKUs as children, these child products will not have their own individual URLs. It is recommended to pass all products and then set the product.is_variant parameter to true for all child products products (those without a unique URL).


Product IDs and SKUs


Often product ID and SKU will be the same value. However for some systems (e.g. where there is a separate product row identifier) these may be different.


Customer IDs / Account IDs


It is often the case that a retailer will have one unique customer / account identifier that they would like used in the primary reporting (for example row ID from the ecommerce customer database). Each contact can optionally supply a customer_id which would be this value. This value is also supplied in the order records when an order is placed by a registered customer (e.g. not a guest checkout) and is used to connect the profile record and the order.

This is different to a contact listing ID in that a profile may have many "contact listings" (with multiple contact IDs) but only one "customer ID" or "account ID".

Note: It's very important that ID's sent to the Ometria system do not contain Personally Identifiable Information (PII) (such as email address, phone number or name).


Contacts and Profiles


Records about people (customers / contacts / leads / subscribers) are supplied as 'contacts' records. Contacts are organised into 'collections'. For example you may have a 'customers' collection (customer records from your ecommerce platform) and a 'subscribers' collection (contact records from your ESP). Each record in a collection is uniquely identified by a string ID.

In this case it may be that the same person exists in each list (or even more than once in each collection). Ometria will attempt to merge these contact records into a single 'profiles' record (based on customer_id and then email address). Thus a single profile record may have several contact records attached.

You cannot write profile records directly as they are automatically clustered by the Ometria system.

It is recommended that contacts from different sources should be passed into Ometria with different collections. This will help to ensure that data on the record is not over-ridden by missing data from another source.


Contact listings Priority

When merging contact records to create a profile, it is sometimes the case that there will be varying parameters on the contact records. When this happens, Ometria will use the following two rules of priority to determine which value to assign to the profile:

Standard Rules of Priority

  1. Preferences centre
  2. API, App, CSV
  3. Ometria Form
  4. Importer (Magento or Shopify)
  5. 3rd party sync

Note:

  • If there are two contact records with the same level of priority, then the varying parameters from the most recent contact record will will be used.
  • firstname and lastname parameters will always be taken from the same contact record.


Marketing Opt-in Rules of Priority

These rules only apply only to a contact's marketing_optin value.

The order of preference

  1. Any Ometria controlled source (eg. Preference centre, Platform, Ometria Form, CSV Uploader)
  2. Any Client controlled source (eg. API, Magento Importer)
  3. Any 3rd Party controlled source (eg. Mailchimp)