STEP 5 Integration review

Introduction

Once you have the integrations done by the development team, it’s time to review if everything was done correctly, according to the checklist in this article.

Below, you can find the checklist to go through in order to make sure the integration is done properly.

Integration review

Tracking code

Check the way the data is stored in the system. Check how many page visits are collected and if possible, compare the amount with other data sources.
If there are not enough page visits, make sure that the tracking code is available on all pages within the domain.
If there are too many page visits, look for pages where page visits are sent more than once (it usually happens on listing or item pages).
If tracker is implemented on a SPA website, check if the page visit events are generated properly as well as if dynamic content works correctly (you can activate a test dynamic content campaign and check if it is rendered).
Make sure that the tracker is not blocked by adblockers & 3rd party cookies (If it is, check the SDK implementation. It’s probably implemented not by tracker in the page’s source code, but by GTM or 1st party tracking mechanism was not set up).

Online Transactions

Check the number of transactions (especially in case of SDK).
Check if there are duplicates of the events.
Check if transaction.charge events generate product.buy events – the number of product.buy events should be equal to number of distinct items bought.
The sum of values of product.buy events generated out of one orderID must be the same as the totalAmount value in the transaction.charge event for that order.
Check if the event data includes the data needed for campaigns and analytics. If you want to use some events parameters later on while preparing analyses, make sure you send them to Synerise. For example, if you send POS transactions to Synerise and you want to analyze the performance of different stores, you should send a custom parameter in addition to the “POS” source indicating the ID of the store where the transaction was made. If it is important to differentiate payment methods for the analysis purposes, such data should be sent as a specific parameter.
The sum of “FinalUnitPrice”’s of product.buy events is the same as the value of TotalAmount in transaction.charge
Check if all the parameters that are sent are registered in the event. Pay attention to the metadata of transaction: sometimes customers send additional custom attributes of transactions outside of the metadata object, and such attributes are not saved.
Make sure that item SKUs in transactional events match the product.retailer_part_no in og:tags and productID in item feed. If you’re not sure if the IDs match, please contact Synerise Service Desk team and ask for a review.
If you use eventSalt in transactions, try to send two events with eventSalt and the same time parameter and see if the transaction has been updated (correct behavior) or a new one was generated (incorrect behavior).
Check if transactions are sent with the correct occurrence time.
Note:
- If you send the time 2020-05-11T05:00:00Z, then the Z parameter indicates that this is a time sent in the UTC time standard.
- If you send no time, the time of receiving the event is inserted.
- If the local time zone is Asia/Kolkata, the time is: 2020-05-11T05:00:00+05:30
- If the local time zone is Europe/Warsaw (DST in effect), the time is 2020-05-11T05:00:00+02:00.
For more details on formatting the date/time string with a time zone, see ISO 8601.
The time of occurrence sent by SDKs/APIs with the event doesn’t affect and isn’t affected by the settings of the workspace.
When the event is saved in Synerise storage, all times are re-calculated into UTC. Then, when you access that event (for example in Analytics or when examining the events of a profile), the portal shows the time re-calculated from UTC into the time zone of the workspace, regardless of the time zone (if any) that was sent with the event.
Ensure that you are not sending a time that is in the future. Such times are rejected and the time of receiving the event is used instead.
Check if the price values are saved in the proper attributes (net/gross).
If you have custom item parameters in the transaction.charge events, verify that the product.buy events for each item include those parameters. When sending the transaction.charge event, these attributes must be sent in each item’s entry in the products array in order to be transferred into the product.buy events.

OG:tags

Go to Catalogs and check if the catalog “Snrs-produktu-ogTag" has been created.
Ensure that the item IDs match between feed and transactions. If you’re not sure if the IDs match, contact the Synerise Service Desk team and ask for a review.
If og:tags are not collected, ensure that they are registered after the initialization of the tracking code.
Visit the item pages and see if data about those products appears in the catalog in Synerise.
Ensure that the tag with item ID is named product:retailer_part_no

Item feed

Make sure that custom parameters start with c: instead of g:
Remember that should be equal to product:retailer_part_no the item IDs in other modules (fields such as SKU and itemId in the APIs/SDKs).
If you want to use custom parameters, ensure that the xmlns:c="http://base.google.com/cns/1.0" namespace is included in the XML prolog.
Check the first line in the feed – feed tags – make sure the headers are the same as in the documentation (RSS or Atom standard)
Ensure that the feed includes all of the required parameters included in the documentation.
Ensure that parameters aren’t duplicated, for example: <link>, <g:link>.
Ensure the items in the feed have all the parameters required to launch campaigns, enriching transactions, and so on.
If you suspect that a value of a tag/attribute might contain the following symbols </>/& you should use the specific format or use the following representation. Example: <g:product_type><![CDATA[Women's Clothing > Jeans > Bootcut Jeans]]></g:product_type> or <g:product_type><Women's Clothing > Jeans > Bootcut></g:product_type>. Warning! Do not combine the > representation with CDATA.
g:product_type must be the same as the category on the website.
Ensure that attributes such as gender and availability are formatted according to Google’s documentation.
Ensure the feed has all the necessary parameters: <title>, <g:availability>, <g:product_type>, <g:price>, <link>, <g:image_link>, <g:id>.
Check the size of the images. If the size is too large, it might influence the speed of loading dynamic content campaigns where you insert data from the feed.
Ensure that parameters which are numbers use a dot (.) as the decimal separator.
If an attribute represents a monetary value (for example g:price or g:sale_price):
- The number must be first and the currency second, for example 15.00 USD
- The currency code must be compliant with ISO 4217.
Product type can have only one of the formats:
<g:product_type><![CDATA[ Man > all > clothes > shirts ]]></g:product_type> , <g:product_type>Man > all > clothes > shirts</g:product_type>

There should be spaces between ‘>’ or ‘>’ otherwise it will be treated as one category. This example will also be stored as one category: <g:product_type><![CDATA[ Man > all > clothes > shirts ]]></g:product_type>
Ensure that all tags in the feed are closed.
Ensure that the feed ends with:
- </channel> and </rss> for RSS.
- </feed> for atom feed.

Cart.status event

Ensure that every change in the cart (including removing items) triggers the event.
Ensure that cart changes are tracked not only the cart page, but also in listings.
An cart.status with an empty cart should be sent after the transaction.charge event in order to clear the cart status.
Ensure that the limit of parameters is not exceeded (2048 characters).
Ensure that cart.status event is triggered only when the status of the cart is changed and by nothing more.
Item ID must be the same as in all of the other transactional events, og:tags, and item feed.
You can check the status of your item for consistency with item-related events. Eliminating discrepancies allows you to improve your item data and optimize your recommendations. See “Item consistency” in “Monitoring Item feed status”.

addToCart/removeFromCart events

Item ID must be the same as in transactional events, og:tags, and item feed.
You can check the status of your item for consistency with item-related events. Eliminating discrepancies allows you to improve your item data and optimize your recommendations. See “Item consistency” in “Monitoring Item feed status”.

Profile management

Check all the places in which customers might leave their data (email, customId, phone, agreements, other attributes). Information from filled forms must be sent to Synerise correctly. Verify that data is saved to profiles (correct update of attributes).
Try the following scenarios on your site and check the results:
First option: anonymous to new recognized
- Open the site in incognito mode and find your UUID.*
- Find the corresponding profile in Synerise. You can search it based on UUID.
- Verify that this profile is anonymous.
- Fill the one of forms on the site, using an email which already exists in one of the profiles.
- After filling the form, refresh the profile in Synerise and check for changes. You should see an update in the email field and extra information which you left in the form.
Second option: anonymous to existing recognized
- Open the site in incognito mode and find your UUID.*
- Find the corresponding profile in Synerise.
- Verify that this profile is anonymous.
- Fill the one of forms on the site, using an email which already exists in one of the profiles.
- After filling the form, refresh the profile in Synerise
  You should see that the profile no longer exists. This is because the anonymous profile was merged into the existing recognized one (recognized before the form was filled in).
- Find the profile by email which you used and ensure that a client.merge event exists in the list of activities.
Third option: recognized to recognized
- Open the site in incognito mode.
- Fill in one of the forms on the site with an email.
- In Profiles, find the profile whose email was used.
- Visit a few pages.
- Ensure that the new page visits are recorded in the profile whose email was used last. If you see activities in the earlier profile, something is incorrect with integration – check UUID reset.
- Fill in one of the forms with a different email address than before.
- In Profiles, find the profile whose email was used.
- Visit a few pages and check events on the client’s profile in CRM, you should see your last activities on the second client’s profile. If you see activities at the first client’s profile, something is incorrect with integration – check UUID reset.
Every form should have a unique tag or parameter indicating the place where clients leave the data, for example login page, newsletter, agreement. Those tags are visible in the profile.

Note: By default, only recognized profiles may be shown in the list. Searching for anonymous customers, remember to change the Show option to All.

Detailed information:

Form integration - more information about trancking form data you can find here.

Check how to find your UUID

Check how to find your UUID in the incognito mode in the video below.

AI model training

Item ID must be the same in transactional events, og:tags, item feed, cart events.
You can check the status of your item for consistency with item-related events. Eliminating discrepancies allows you to improve your item data and optimize your recommendations. See “Item consistency” in “Monitoring Item feed status”.
Make sure you meet the minimum data requirements to launch the models.

Detailed information:

AI requirements - more information about AI models requirements, you can find here.

Help center documentation

Learn more about Synerise funcionalities from our documentation in Help Center.

Learn more →

Use cases

Discover our use case base and check how to use them in practice.