STEP 3 Events


Introduction


Synerise platform mainly works on events. In the parameters of each event you can pass detailed information about specific interactions with all customer/brand touchpoints. Within the event, we collect data about interactions such as page visits, displaying dynamic content in mobile app, opening the newsletter and so on. The event is the main data in Synerise that we can collect and later use to create personalized communications, recommendations and analytics.

From this chapter you will learn:

Arrow down iconhow to implement transactions,

Arrow down iconhow to import historical transactions,

Arrow down iconabout the cart.status event,

Arrow down iconabout OG tags.

Events


The tracking code collects events, which store the data of touch points with your brand (all customer’s activities on the website). For example, opening the page is saved as the page.visit event.

Sometimes, events also define the activities directed at the user, such as sending an email (message.sent) or a web push notification (webpush.send). The application can generate these events thanks to the implementation of a tracking code and/or SDKs and the API.

  • Some events are collected by default, for example:

    • page visits
    • session start/end for anonymous users
    • system events such as: message sent, newsletter open
  • Other events must be implemented additionally, for example:

    • adding to cart
    • transactions
    • adding to favorites
    • button clicks
    • and anything else you need to track, including custom events
Detailed information:

Implementing transactions


Arrow down icon Why you need this integration: To collect transactional events in real-time.

Arrow down iconWhat type of campaigns require such integration: You will need this data for ecommerce performance analyses, creating more advanced segments for campaigns, creating an abandoned cart campaign, training AI recommendation models such as cross-sell.

Transaction events are one of the most important events that you can store in Synerise. You store them as a transaction.charge event with all the details regarding the transaction, for example which products have been bought (products parameter), the transaction value ($totalAmount parameter), the discount value ($discountAmount parameter) or the transaction source ($offline parameter), and so on. Additionally, each transaction.charge event generates an additional product.buy events. They are generated separately for each bough product, which means that in a transaction event with 5 different product IDs generates 1 transaction.charge and 5 product.buy events in Synerise. The product.buy event stores data about the product bought (ID, price, color, link, and so on).

Both the product.buy and transaction.charge events will consist of default (required) and custom attributes. A few examples of custom attributes are information about the chosen delivery option, ID of the point of sale (POS) where the transaction was made, used coupon, and so on. You can use any custom names for such attributes. With default attributes, however, you should follow the Synerise guidelines as those must be named in a specific way and should have a specific format. Such attributes are tagged with a special ‘$’ character in the name, such as:

transaction.charge:

  • $currency
  • $orderStatus
  • $paymentType
  • $offline
  • $source
  • $revenue
  • $totalAmount
  • $orderId

product.buy:

  • $currency
  • $regularPrice
  • $discountPrice
  • $finalUnitPrice
  • $netUnitPrice
  • $tax
  • $orderStatus
  • $sku
  • $quantity
  • $name
  • $image
  • $categories
  • $category
  • $orderId

Ways to integrate online and offline transactions


Integration by JS SDK

  • with dataLayer
  • with syneriseLayer
VERIFICATION - SEE THE CHECKLIST icon

VERIFICATION - SEE THE CHECKLIST

This section provides a verification checklist for ONLINE TRANSACTIONS to ensure that all of the necessary steps are taken. It includes a list of information that must be collected and evaluated to make sure that everything works.

Learn more →
Detailed information:

Integration by API

Online transactions can also be integrated by the API.

You have to create an API key with the appropriate scope and permission.

Note: The SKU in the transaction frame must be the same as the product:retailer_part_no and product ID in the product feed.
Detailed information:

Other ways of integration

The integration way described above is the default one. There are also additional options such as:

  • Running a file import through Data Transformation modules – data will be transferred to Synerise in files. There is a possibility to import such a file manually and/or schedule an import from SFTP/FTP. The minimum necessary transaction details should be included in the file and formatted according to the documentation in order to upload the file. If the data format is different from Synerise requirements, check if the data might have been automatically transformed in Synerise Shovel (the import module). If so, remember that once defined, the data structure should remain the same for all imports made with that configuration.
  • If you can’t use the default way of integrating transactions, you can choose the incoming webhooks integration. Synerise will generate a custom endpoint which can receive any custom data format. The events might be sent out as soon as the endpoint is configured. However, it is necessary to prepare a specific configuration of the data flow. To do this, go to the Automation module and create a path, which will capture the data frame of a transaction, convert it into a format corresponding to Synerise and send it to the customer’s card. Remember that currently, requests sent to incoming webhooks are not authorized in any way (we are working on introducing this functionality), while each endpoint is generated individually for a specific integration on a given workspace.
Detailed information:

Event salt


This parameter is used for example to generate an UUID for the transaction event. When a transaction has an eventSalt, it can be overwritten by sending another transaction with the same eventSalt and recordedAt as the original transaction. A transaction that has no eventSalt cannot be overwritten. The parameter cannot be added at a later time.

Important: eventSalt must be unique in the whole system. The parameter cannot be retrieved later. You must keep track of the values that you send. In case we use an eventSalt , it is necessary to check if the overwritten events are stored properly in the CRM and analytics

Import of historical transactions


Arrow down iconWhy you need this integration: To store historical transaction information in the system and provide data for AI models.

Arrow down iconWhat type of campaigns require such integration: When you want to launch an AI campaign, our algorithm will need data to learn from. If you’ve already been working on Synerise for a while and there is already a substantial amount of data in the system, this step may be skipped. However, if you’ve just started your journey with Synerise and there is no data in the system yet (or small amounts), then it is necessary to supply our algorithm with historical data for some AI campaigns.

Arrow down iconWhich types of AI campaigns require transactional data: Cross-sell, cart recommendations, bestsellers.

Note: The documentation below describes the entire import process. Remember that productID/SKU must be the same as product:retailer_part_no.

cart.status event


Arrow down iconWhy you need this integration: This will give you exact information about what products a customer had in their cart.

Arrow down iconWhat type of campaigns require such integration: It will be used for AI cart recommendation campaigns and abandoned cart emails, but it will also let you prepare dynamic content campaigns on the cart level – for example, if a user has 2 items from the same brand in their cart, you can show them a promotion.

This step is not mandatory, but it has an impact on the quality of the recommendations and abandoned cart scenario.

VERIFICATION - SEE THE CHECKLIST icon

VERIFICATION - SEE THE CHECKLIST

This section provides a verification checklist for CART STATUS EVENTto ensure that all of the necessary steps are taken. It includes a list of information that must be collected and evaluated to make sure that everything works.

Learn more →
Detailed information:

OG:tags


OG:tags are specific <meta> tags in the item’s page HTML code that describe the details of the item.

For example:

<!DOCTYPE html>
<html lang="en">
<head>
...
<title>First Steps :: Synerise Hub</title>
<!-- OG tags -->
<meta property="product:retailer_part_no" content="1a4d3380"> <!-- obligatory! -->
<meta property="og:title" content="First Steps" >
<meta property="og:url" content="/first-steps/" >
<meta property="og:description" content="Learn how to use Synerise efficiently, to have greater impact on your customers, and to overcome every challenge that your brand faces. Visit this section frequently, as we add more and more use cases regularly" >
<meta property="og:image" content="https://upload.snrcdn.net/9bbb7035ecf3565cceed63d321d7d9b31236850d/default/origin/d566594dc7f7a725f4fa9578457aab8f.png" >

The metadata must be included after the script which initializes the tracking code.

The most important tag is product:retailer_part_no, which is the item’s unique ID (same as the itemId in the item feed, or the SKU in API requests). This tag is obligatory. It lets you associate page view events with a particular item.

They come in two forms:

  • og:property_name - basic information such as type, image, site_name, url
  • product:property_name - additional information such as price, brand, color, and so on

Whenever a page.visit event is sent, all the OG tags of the viewed page are included in the event data. This allows you to use that information, for example in Automation, or in Jinjava inserts.

Additionally, the OG tag data from page.visit events is automatically saved to a catalog named Snrs-produktu-ogTag. You can use data from this catalog in inserts or automations, but an item’s data is only updated when someone visits the page, so it’s not recommended to rely on this catalog as the primary source of data. The catalog is useful for checking if data from events is collected properly.

Note:

If too many OG tags are sent with a page.visit event, they may be blocked by the browser due to too many characters in the request. In case of exceeding the limit, page.visit event is sent without og:tags. These are the limits for different browsers:

Browser Request length
Google Chrome™ 32779
Android™ Browser 8192
Firefox >64k
Safari® >64k
Internet Explorer 112047
Microsoft Edge 16 162047
VERIFICATION - SEE THE CHECKLIST icon

VERIFICATION - SEE THE CHECKLIST

This section provides a verification checklist for OG:TAGSto ensure that all of the necessary steps are taken. It includes a list of information that must be collected and evaluated to make sure that everything works.

Learn more →
Detailed information:
Help center documentation tile illustration
Help center documentation
Learn more about Synerise funcionalities from our documentation in Help Center.
Use cases tile illustration
Use cases
Discover our use case base and check how to use them in practice.
😕

We are sorry to hear that

Thank you for helping improve out documentation. If you need help or have any questions, please consider contacting support.

😉

Awesome!

Thank you for helping improve out documentation. If you need help or have any questions, please consider contacting support.

Close modal icon Placeholder alt for modal to satisfy link checker