FAQ Repository

Email
  • 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.


    On this page:


    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 op-tin priority.

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

    JavaScript
    “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.

  • As it's unusual that two different reporting sources have the same attribution logic, they often report different revenue, numbers of orders and visits.

    It's common for attributed revenue in Ometria to differ up to 15-20% from revenue reported by Google Analytics (GA) because the two tools count visits in different ways.

    However, where the differences are more significant, it’s worth looking at in more detail to find out if there is a wider issue. 


    On this page:


    Attribution in Google Analytics

    Google uses a last click attribution model. This means that GA counts the last visit the contact made before placing an order.

    Even if a contact was prompted by an email, they might have visited via a Google search, in which case GA attributes the order to ‘search’.

    The contact may also leave your site (after having clicked through from an email) to look for a coupon code and then return to your site again. Even if the contact doesn’t find a coupon code, the most recent visit will have been via Google search, so GA attributes the order to ‘search’. 

    If you have sent the contact a coupon code and the contact copies and pastes it some days after receiving it, visiting the site via a saved bookmark, GA will attribute the order to ‘direct visit’, as it has no information on where the coupon code came from.


    Attribution in Ometria

    By default, Ometria attributes orders based on:

    The time window means that if the contact opens an email, clicks on it and arrives at your site, but later leaves and comes back again within two hours of the first click, Ometria attributes any order they place to the original email.


    Troubleshooting attribution discrepancies 

    If you suspect a problem with your revenue attribution, the first thing you should do is take a sample of orders within a specified date range (e.g. seven days) from Ometria’s orders report

    Cross reference the Visit medium in the orders report with a sample of orders from the same date range in Google Analytics (using GA’s source medium).

    This way you can see which sources are misaligned, which should indicate where to look next. 

    In particular, look out for orders that Google Analytics attributes to a known source which Ometria has marked as either Not tracked or Not provided.


    StatusDescription

    Not provided

    There was a visit associated with the order, but the UTM parameters: 

    • didn’t exist in the first place,
    • were stripped out by a third party provider and cannot be found, or;
    • are not recognised by Ometria

    so that Ometria couldn't attribute the source. 

    This status also includes direct visits, as no parameters would be passed with the event. Direct visits can still be attributed by coupon attribution or time window attribution.

    Not tracked

    Ometria does not have the tracking information for the visit for a variety of reasons.

    Examples:

    • The contact was using private browsing (i.e. Incognito mode).
    • An ad blocker prevented the tracking information from being sent.
    • The order occurred before you (the retailer) were using Ometria.
    • A JavaScript issue.



    When Ometria is reporting lower revenue from email than Google Analytics

    If Ometria’s revenue from email is lower than in Google Analytics, any of the following may account for it.

    If you think any of the issues in this article might be the case, contact support@ometria.com or your customer success manager.

    Your JavaScript is not correctly implemented

    JavaScript tracking on your site tracks your customers’ visit sessions and activity.

    If the JavaScript is not correctly implemented, it may cause discrepancies in your reporting statistics. 

    Take the following actions to test your JavaScript tracking:

    1. Open a campaign email and click a link through to your website.
    2. In your browser, add #om_debug ‘to the end of the URL (e.g. so www.abcshop.com/#om_debug)
      • If the JavaScript is working correctly, a small box pops up in the top right of your screen, which tracks your session through the website:

    • If no box displays, there could be a JavaScript tracking issue. 

    A data integration error

    There may be an issue where some orders are not being sent to Ometria from your importer or API. 

    Take the following actions to test your data integration:

    1. Place a test order on your site.
    2. Refer to the orders report and see if your order has been captured. 

    The JavaScript is being called for orders that are not yet valid

    Some ecommerce stores are set up so that orders are only defined as valid once they are shipped, meaning that revenue is not fully accounted for until hours or days after the order is placed.

    Take the following actions to test:

    1. Place a test order on your site.
    2. Refer to the orders report and see if your order is listed as Valid

    Recent changes to your website

    If you’ve recently added new pop-ups, footers and web pages to your site, the JavaScript tracker may not have been implemented correctly.

    Take the following actions to test your JavaScript tracking for your new pages:

    • Open a campaign email and click a link through to your website.
    • Navigate to one of the new pages and add an #om_debug to the end of the URL.
      • If the JavaScript is working correctly, a small box pops up in the top right of your screen, which tracks your session through the website:
    • If no box displays, there could be a JavaScript tracking issue. 

    Missing or incomplete UTM parameters

    UTM parameters, or ‘tracking parameters’ ensure that revenue is attributed to the correct source.

    See Tracking parameters overview for more information.

    To test your UTMs, take the following actions:

    1. Open a campaign email and click a link through to your website.
    2. Check that the URL of the page you land on contains tracking parameters.

    Payment gateway redirecting

    If your payment gateway redirects contacts from your site in order to pay for their order (e.g. PayPal), the redirect link might be stripping out the tracking parameters.

    To test your UTMs in this case, take the following actions:

    1. Place a test order on your site using a payment method which will redirect you to another site.
    2. Refer to the orders report and see which source your order was attributed to. 

    When Ometria is reporting higher revenue from Google Analytics

    If Ometria’s revenue from email is higher than in Google Analytics, any of the following may account for it.

    If you think any of the issues in this article might be the case, contact support@ometria.com or your customer success manager.

    Missing or incomplete UTM parameters

    UTM parameters, or ‘tracking parameters’ ensure that revenue is attributed to the correct source.

    See Tracking parameters overview for more information.

    To test your UTMs, take the following actions:

    1. Open a campaign email and click a link through to your website.
    2. Check that the URL of the page you land on contains tracking parameters.
    You should check that the parameters are not just Ometria specific ones (beginning with om_), but also source_medium=email- which Google Analytics uses for attribution.

    Orders paid via PayPal or other third parties

    Orders which are paid for using PayPal or other third parties are not always tracked by Google Analytics, whereas Ometria can still attribute orders in some (not all) cases where UTM parameters are stripped out by payment gateways.

    This means that if the payment page on your site redirects to PayPal or another third party payment page and strips the parameters, then Google Analytics can’t track the transaction.

    To test your UTMs in this case, take the following actions:

    1. Place a test order on your site using a payment method which will redirect you to another site.
    2. Refer to Google Analytics and see which source your order was attributed to.

     

  • There are several reasons why a particular contact has not received a specific automation campaign, and before digging further you can run through this checklist to see what might have prevented them receiving it:


    1. The email has been sent, but the contact has not received, seen or opened it

    Check that the email has been sent by going to Campaign performance and selecting the relevant campaign:

    Next, select the Activity tab and check the Status column to see if the email was delivered:


    2. Is the contact opted-in to receive marketing?

    Check that the contact has agreed to receive marketing emails by going to their profile.

    Subscription status displays in the top left panel of the screen:

    If the contact’s subscription status is Unsubscribed, they will not receive emails from you.

    If the contact’s subscription status is No preference, then they are normally not eligible to receive marketing emails from you. If you want to find out in what circumstances they might be able to receive emails, please speak to your CSM.


    3. Does the contact meet the requirements for the campaign segmentation?

    Check the segmentation set up in the campaign, either in the automation flow itself, or from Segment explorer.

    Confirm that the contact meets the conditions for the segment. 

    Be aware that segments used in automation campaigns refresh every six hours, so if the contact did not meet the segment conditions more than six hours ago, they will not have entered the campaign. 

    For example, if you had set an email to trigger once a day, then the contact will not enter the campaign until the following day.


    4. Does the campaign have an exit condition?

    Check the campaign flow for any exit conditions which might have caused the contact to leave the flow. 

    For example, if you have an exit condition which triggers when a contact places an order, the contact will drop out of the campaign once they’ve ordered, and won’t receive any follow ups. 


    5. Do you have rate limiting set up?

    Check your Email settings to see if there is a maximum limit for emails sent over 24 hours or 7 days:


    Note: Only users with administrator permissions can view and edit these settings. 


    If contacts can only receive one automation email per 7 days, this may be the reason your contact has been disqualified from receiving this email.


    6. Do you have mutual exclusivity set up for the campaign?

    Ometria has a number of options available to ensure mutual exclusivity, i.e. to prevent your contacts from entering campaigns if they are already active in others, therefore stopping them from receiving too many emails from you. 

    Check your mutual exclusivity by going to the automation campaign flow and selecting Settings.


    For more information on how automation campaigns work, please refer to these help documents:

  • There are a number of reasons why a specific product might not be appearing in our product recommendations. 


    1. Does the product qualify?

    Depending on the type of product recommendation you are using, it’s possible that the product does not qualify - e.g. if it has not been browsed by the recipient in the past few months, or it is not one of your top sellers.


    2. Has the product been set up correctly?

    You should check in your ecommerce system, to make sure that the product data you are sending Ometria is complete. 

    For definitions, see: Products, product listings and product variants

    For example, the most important data fields we need to ensure products are included in product recommendations are:

    FieldDescription

    is_active

    This field should be set to TRUE at the product parent level.

    If it is set to FALSE, Ometria assumes the product is inactive/no longer available, and it will not qualify for product recommendations. 

    is_in_stock

    This field should be set to TRUE or NOT DEFINED at the product parent level.

    If it is set to FALSE, Ometria assumes the product is out of stock, and it will not qualify for product recommendations. 

    You should also check that your parent product has:

    • A defined price greater than ‘0’
    • A URL

    A common problem is that the child product (e.g. red bag A, green trousers B, etc.) has a price and URL, but the parent product does not. 


    Note: Ometria’s product recommendations display parent products only, not child products. This is because in most cases child products don’t have their own landing pages or unique URLs.


    Where ecommerce stores have a different setup, i.e. every child product has its own unique page, it’s important that the parent product has a unique URL of its own, otherwise it cannot be displayed in Ometria’s product recommendations.

  • There is no limit.


    There should be no limit on an individual field, just the overall limit on the entire size of all custom fields for a contact (1kb Json encoded).


  • In Ometria we use definitions set by ISPs to classify different bounce codes and their meanings.





    The logic we use to determine different bounce categories in campaign reporting is as follows:

    Soft bounces: 20, 21, 22, 23, 24, 40, 60, 70, 100

    Hard bounces: 10, 30, 90

    Email bounces: All of the above, plus classes 50, 51, 52, 53, 54


    How can delivery rate be 99% if X% of emails are delayed?

    Because delayed emails still get delivered, if you look over 24 hours, maybe X% got delayed and re-sent, so delivery can be 99%.


    What are delayed emails?

    Delays (aka Temporary Failures or 4xx Errors)

    When we receive a 4xx rejection from the ISP, we log a "delay" event that includes the timestamp and the attempt count and retry again later.  

    If we hit the maximum number of retries (or maximum time period the message is eligible for delivery) and the remote server still has not accepted the message, we will fail the message with a timeout reason – in this case we will log a "bounce" event.  
    These types of bounces (those for which the remote server continually rejects the message with a 4xx error) are not usually classified as hard bounces.

    Hard Bounces (aka Permanent Failures or 5xx Errors)

    When we receive a 5xx response from the ISP, we will log a "bounce" event and determine the bounce classification based on the 5xx response string.  (Bounces classified as "hard" bounces (code 10) are added to the suppression list.)


    How long are emails delayed before we do not push them anymore? i.e. people receiving promos after they have expired.

    On the first failure the message is sent to the delayed queue and retried 20 minutes later.On the second failure, the retry interval doubles to 40 minutes.On the third failure, the retry interval quadruples to 80 minutes.On the fourth failure, the retry interval multiplies by eight, to become 160 minutes.


    Why do 'email hard bounces' and 'email soft bounces' not add up to 'email bounces'?

    Because you also have admin bounces and block bounces:
    Blocked – These emails were refused because the recipient server determined that the content is spammy, the IP has poor reputation, or a myriad of other filter verdicts. These are rejected at the recipient server level, and never reach the intended recipient.
    Admin – These emails were blocked due to a previous unsubscribe, spam/feedback loop complaint or hard bounce.  Admin Failures are a result of our system monitoring and protecting your sending reputation. 


  • In order to make use Ometria segments in Google for remarketing (provided we have synced these for you), please refer to this Google guide as to what steps need to be followed.

     

    If you need further help, please contact support@ometria.com for further assistance.


  • You  would not need a separate unsubscribe link as the preference center  would allow uses who have "subscribed" status or "unknown" status to  unsubscribe from marketing.


    If you are having any issues with this please contact us at support@ometria.com


  • You can use the product feed to display products abandoned/viewed/purchased.


    Here is the Facebook guide on how to implement dynamic adds.


    The  sync'd segment should appear in Facebook as a custom audience you can  select to target when you create the ad in Facebook. The audience name  will be the name of the Ometria segment.

  • Why  am I unable to view a preview of my email template? Coded view  displayed like the one below but cannot be opened using the preview  button or not showing next to the coded version?


    Frequently, a missing preview is due to an error in the HTML - please ensure that  the HTML code you are using is valid. This would be the primary reason  this is not displaying correctly.

     

    If you have validated the HTML and are still unable to preview the template please contact support@ometria.com.

  • If  you would like to find out how many items/products customers have  bought, you can see this at an individual customer level on the customer  profile screen, as below:



    If you would like to see how many (and which) customers have bought more than X items in a date range, you would use the orders report.

    1. Choose the date range you want.

    2. Navigate to the Orders by Customer screen.

    3. Choose the "Columns Selected" and select the data you want (selecting all can generate too big a file to download).

    4. Download the customer list into a CSV file, and order the file by number of items bought.



    All data used is randomly generated and for illustrative purposes only.


  • Our templates can support images up to 300KB.


  • There could be several factors causing this:

    • We  can only report on the data you send Ometria, and often this is the result of contacts abandoning the site or identifying themselves on site without explicitly being asked if they want to receive emails. This would result in an "unknown" status.
    • The ecommerce platform may not be setup correctly - i.e. contacts are automatically opted in with a pre-ticked check box. If the system does not pass these contacts to their subscriber list, Ometria will not receive their subscriber status, but will receive the contact as attached to the order.
      Conversely, if people do not check the box, it may not mean they have explicitly opted out so their status would still remain 'unknown'.


  • Delays (Temporary Failures or 4xx Errors)

     

    When  we receive a 4xx rejection from the Internet Service Provider (ISP), we  log a "delay" event that includes the timestamp and the attempt count  (example: "num_retries":"6") and retry again later. The proprietary  retry algorithm attempts delivery for each message a certain number of  times over a time period; the process is dynamic but it would not be  unusual for a message to be retried up to 6 times over 72 hours.


    If  we hit the maximum number of retries (or maximum time period the  message is eligible for delivery) and the remote server still has not  accepted the message, the message will be failed with a timeout reason –  in this case we will log a "bounce" event.  The bounce classification  routine will use the last 4xx response string to determine what type of  bounce should be recorded. 

    Note:  These types of bounces (those for which the remote server continually  rejects the message with a 4xx error) are not usually classified as hard  bounces they are soft bounces.


    There is also another type of delay that we may see:

    "reason":"451 4.3.0 [internal] Sending IP temporarily suspended"

    These  delays are due to the Adaptive Email Delivery (AEN) doing its job. The  AEN is an integral part of email delivery that moderates traffic to  comply with ISP/server rules and feedback. When we get push back from  them, software detects these bounces and takes the appropriate action to  "back off" of the receiving endpoint. Listening to feedback from ISPs  allow us for a better reputation, resulting in higher deliverability for  everyone on the platform.


    ISPs  delay messages for multiple reasons such as mail server busy or over  loaded at the time of send, etc. Like other Delays, they are retried  until delivered or timing out after 72 hours.

    The  AEN is only acting on the behavior of the ISP and is meant to hold onto  your message until the ISP is able to accept it rather than receiving a  block bounce and not delivering at all.  It works on the concept of  better late than never.

     

    It  is generally not a good idea to send huge amounts of emails if one go  if you have not sent a lot of emails previously as a ISP delivering your  emails may view these as spamming. You would effectively need to "warm  up" the ISP (hotmail, gmail, talktlak etc) to you sending emails to them  as sending a whole load all of a sudden with no previous sends could  lead to lots of your emails being classed as spam or being delayed.


  • This can occur due to there being a time  lag between the API reporting orders and our conversion/visit tracking,  which is real time.

    In most cases we can identify products bought  via the java script, but in some cases this is not possible and we have  to wait for the API to report them. So the orders report will be  accurate, but there may be some discrepancy in the real time view.


  • The conversion rate is calculated based on valid tracked orders over visits.

    A  tracked order is an order where we know the visit came from. If we look  at the KPIs selected and check valid tracked orders you’ll see that the  numbers add up.

  • We do support custom fonts/web fonts, however, web fonts aren't supported by all the email clients.


    See this link for further information:


    Litmus guide to web fonts.


  • Product ID is used.


    If you change the SKUs could you inadvertently lose any information?

    No, as we use product ID as long as these remain the same the SKU can be changed.


  • This is determined by an "Explicit" record coming from the integration method with your contacts such as Magento or Shopify or via an "Implicit" method when we collect the record via a form.


    Explict: e.g. from magento customer records or shopify customer records
    Implicit: From the 'name-title' with the following logic: Mr = male, Mrs, Miss, Ms = female


Data
  • For Magento integrations Ometria uses the currency conversion that has been set up in the Magento instance.


    For all other integrations Ometria uses rates from:


    openexchangerates.org

    • CSV and XLSX exports are limited to 1 million, so you can only export 1 million rows of (contact) data at a time.

    • There is a notification set on the export button which will remind you of this.

    • If you do attempt to download a file with more than 1 million rows then it will simply limit at 1 million.

    • If you do need to download a CSV or XLSX file with more than 1 million rows please attempt to use a workaround (i.e. creating a series of smaller lists, downloading and combining.)  

    • However, if this is essential we are able to export it for you via a support ticket.  It will take a day of engineering time to do this, however, delivery timing depends on support capacity; when the ticket comes in we will provide an estimate.


    Note - if you attempt to split a segment with 1 million or more contacts this will also cause issues and crash your usage of Ometria.