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:

how to implement transactions,

how to import historical transactions,

about the cart.status event,

about 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

Implementing transactions

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

What 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

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 →

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.

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.

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.

Import of historical transactions

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

What 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.

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

cart.status event

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

What 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

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 →

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.

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 →

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.

Learn more →