What are events and how to use them?

Events described in this article are new and different feature than the custom events currently used in Marketing Automation.

What are events in GetResponse?

Events are created to answer the needs to react to the vistor’s behavior on the website by:

  • collecting information about user behavior,
  • using and responding to them through functionalities and channels within GetResponse (right now they can be used in popups).

At the moment events can be recorded only on the browser’s side using Web Connect, which forwards them directly to GetResponse for the purposes of operations on user segments.

Which events can be created now?

At present you can use two events:

  • viewItem – trigger based on a single product view
  • viewCategory – trigger based on any product view from a chosen category

How to use events to trigger popups created in GetResponse?

You can do that while creating popup based on product view using our popup editor.

How events are passed to GetResponse?

The whole process requires:

  1. Creating the store.
  2. Getting the store id.
  3. Payload for every event.

An example of a single trigger:

  • In each trigger, the product and category fields contain product IDs that you can indicate on the trigger popup form.
    Important note: to use these IDs later in triggering events on the website, you need to use the same data.
  • If you will select many products/categories, the fulfillment of the condition will work on the OR basis. So, if you indicate product A, product B, category A and category B and in the how many times? field, you indicate exactly 5 times, then if the visitor will see product A 5 times and not once product B, category A or category B, the condition will be considered as fulfilled.
  • trigger is based on viewItem and viewCategory events that you (or ecommerce integration) can trigger from the JavaScript code on your website. These are two separate events, the occurrence of the viewItem event does not automatically imply the occurrence of the viewCategory event (and vice versa), they must be separately and explicitly triggered when the visitor enters the product or category page, respectively.
    Both, Web Connect code and event trigger code, must appear on all pages.

To trigger the viewItem or viewCategory event, put the following JavaScript code (anywhere on the page, but under the <script> tag containing the Web Connect snippet):

GrTracking('importScript', 'ec');
GrTracking('viewItem', {
    product: {
        id: 'productIdPointedInGetResponseInTriggers',
    },
}); // trigger viewItem
// or
GrTracking('viewCategory', {
    id: 'categoryIdPointedInGetResponseInTriggers',
});

The above example operates only on the required fields from the viewItem and viewCategory event interfaces, the full interface looks like this:

GrTracking('importScript', 'ec');
GrTracking('viewItem', {
    shop: {
        id: 'shopIdOptional',
    },
    product: {
        id: 'productIdPointedInGetResponseInTriggers',
    },
}); // trigger viewItem
// lub
GrTracking('viewCategory', {
    shop: {
        id: 'shopIdOptional',
    },
    id: 'categoryIdPointedInGetResponseInTriggers',
});

Limitations

Ecommerce events (as well as all other events used for popup triggers) are collected and stored on the visitor’s browser. In particular, this applies to subdomains, events between subdomains cannot be used, i.e. events collected by the customer on the website https://example.myshop.com will not be available on the website https://blog.myshop.com.

Events are available until the site visitor clears the browser’s data. They are collected from the moment the Web Connect snippet is placed on our website together with the invocation of appropriate methods that trigger the event (or from the moment of activating the integration that will do that for you, also, events between integrations cannot be used).

Future functionalities

We plan to continuously develop events so that they can be used for:

  • building the possibility of presenting content to users on the basis of collected events through the automation editor (or in the future the events flow editor):
    • the possibility of multiple processing of events in Automation, so as to properly direct the user to different paths based on his activity,
    • enabling clients to access predefined sets of event processing, for example: handling ecommerce/product events and communication aimed, for example, at restoring shopping carts,
  • activating undecided users by offering coupons, discounts, recommendations, etc. analysis of the effectiveness of actions,
  • supporting the process with A/B tests for defined event paths.