--- ## 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.send) 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 - [Events](/docs/assets/events) - read more details about events, their types and places in Synerise in which you can find them. Among this chapter in documentation you will find information about: - [Definitions](/docs/assets/events/event-definitions) - [Event parameters and enrichment](/docs/assets/events/adding-event-parameters) - [Event authentication settings](/docs/assets/events/event-settings) - [Synerise event reference](/docs/assets/events/event-reference/default-events) ## Implementing transactions --- Arrow down icon **Why you need this integration:** To collect transactional events in real-time. Arrow down icon**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 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. - [Creating a transaction by JS SDK](/developers/web/transactions-sdk) - learn more about creating a transaction by JS SDK. #### Integration by API Online transactions can also be integrated by the API. You have to create an [API key](/docs/settings/tool/api) with the appropriate scope and permission.
The SKU in the transaction frame must be the same as the `product:retailer_part_no` and product ID in the product feed.
- [Creating a transaction by the API](https://developers.synerise.com/DataManagement/DataManagement.html#operation/CreateATransaction) - learn more about creating a transaction by the API. #### 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. - ["Import Transactions" node documentation](/docs/automation/actions/synerise-integrations/import-transactions) - [Use case example with Data Transformation](/use-cases/import-transactions-dt) - 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. - [Incoming webhook node](/docs/automation/integration/incoming-webhook-node) - learn more about incoming webhook node. ### 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.
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 icon**Why you need this integration:** To store historical transaction information in the system and provide data for AI models. Arrow down icon**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. Arrow down icon**Which types of AI campaigns require transactional data:** Cross-sell, cart recommendations, bestsellers.
The documentation below describes the entire import process. Remember that productID/SKU must be the same as product:retailer_part_no.
- ["Import Transactions" node documentation](/docs/automation/actions/synerise-integrations/import-transactions) - [Use case example with Data Transformation](/use-cases/import-transactions-dt) ## cart.status event --- Arrow down icon**Why you need this integration:** This will give you exact information about what products a customer had in their cart. Arrow down icon**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. This section provides a verification checklist **for CART STATUS EVENT**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. - [Cart.status documentation](/developers/web/cart) - learn more about the cart.status documentation ## OG:tags --- OG:tags are specific `` 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.
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
This section provides a verification checklist **for OG:TAGS**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. - [OG:tags documentation](/developers/web/og-tags) - OG tags are described in more detail in the Developer Guide.