System Events

System events are a group of events available to all Bloomreach Engagement customers by default without the need for a specifically tailored integration. As opposed to custom events, system events should be the same for all Bloomreach Engagement users. This article lists and explains the attributes of these events.

session_start, session_end, first_session

🚧

Ghost sessions

A session_start and session_end (but not page_visit) can occasionally be tracked without the customer being active. This can happen when the customer leaves your website running, their computer falls asleep, and then their browser gets randomly active and generates a session ping without any page_visit. Read more about this occurrence and our solutions for it in Ghost sessions.

The duration of the session will be the difference between the timestamps of session_start and session_end in seconds. The timestamp of the session_end will have a timestamp within 2 minutes after the customer closed the last page (the 20-minute timeout is ignored for the purpose of calculating the session duration).

In other words, the timeout ensures that if someone closes the page but returns within 20 minutes, this will still be counted as a single session. However, if they do not return, those 20 minutes will not be counted into the session duration.

The events are tracked with the following properties (you can add custom ones using the Javascript SDK's ping options):

📘

Special object timestamp event attribute

The special object timestamp event attribute denotes a timestamp different to the custom-tracked event timestamp attribute. It might be used, for instance, when you want to urgently change tracking of the timestamp to a different format (for example, string YY-DD-MM format instead of a datetime) because of a specific use case. However, it is recommended to use this solution only temporarily and aim to update the format of the custom timestamp event attribute to avoid confusion between the two in the long run.

📘

Using Google Analytics ID for first_session

If you have just started using Bloomreach Engagement and you had tracked your customers using Google Analytics before, you can use the Google Analytics ID to immediately distinguish between old and new customers also in Bloomreach Engagement. You can get the Google Analytics ID from the Google Analytics tracker. Google Analytics ID is written in the form 1.2.286403989.1366364567 and it's last part (behind the last dot) is the timestamp of the first session. In Bloomreach Engagement, you can extract it from Google Analytics ID using an expression and store it as a customer attribute.

🚧

Customer's location inaccuracies

As all the attributes that localize the customers are based on their IP, they depend on the quality of the IP infrastructure. The country and city attributes are generally very reliable, however, the latitude and longitude are often not (as they are a more precise measure of the customer's location).

session_start custom attributes (deprecated)

session_start is often complemented with these manually added custom attributes. These attributes are deprecated.
If you want to try to add some of them as custom attributes, read on how to add default attributes to events and set up advanced tracking parameters in the Web tracking article.

session_start and session_end activity properties

activity properties are sent by the Javascript SDK in session pings.

page_visit

page_visit happens each time the customer opens one of the pages of your website. Note that these events are disabled by default but you can enable them using the track options of the Javascript SDK.

🚧

Issues with the tracking

If you are using our CDN page outside of your own domain for giving out surveys/getting consent, no page_visit or session_start events will be generated.

campaign

The campaignevent is generated when working with emails, SMS/MMS messages, WhatsApp, push notifications, or webhooks.

🚧

Permissioned Access to Campaign Event Settings

Campaign Settings now have permission access. Any change to mapping can be executed only after a discussion with Account Managers.

Values of the status attribute

Which status attributes are generated by each channel

Values of the code attribute

Code attribute gives you the SMTP error or reply code received from a server after you send out a campaign email. The status attribute is based on these codes, however, it is useful to also know the code itself as it is more precise in assessing what happened to the email. The following link contains a list of codes and their corresponding meanings. For these to work correctly, you need to have a Mailgun integration. Even though SMTP codes are reliable for most customers, beware that small email providers often send alternative SMTP codes that will not be recognized.

📘

Tracking clicked event

Links to your webpage sent out in a campaign lead to our CDN domain first so that the clicked event is tracked. After that, the customer is redirected from the CDN domain to your webpage.

🚧

Issues with the opened event

Opened event tracked for Gmail does not guarantee that the recipient had indeed opened your email. Gmail's servers sometimes download external images from emails into their cache in advance. As we use these images to track whether the customers opened the email, we get a fake open event every time Gmail's servers do this. Moreover, email providers sometimes block the loading of the images we use for the tracking of the opened event so even if your email seems to be just delivered it might, in fact, be opened.

Bounce management

When an email does not get delivered, there might be multiple reasons why it happened. We collect the failure feedback from our email providers and automatically assign them to standard bounce categories such as soft bounce (for example, full inbox) or hard bounces (for example, invalid email). Bloomreach Engagement also works with our custom type of bounce, what we call a “cumulative bounce”! Read all the details in our article for Bounce Management.

Status name change and filters migration

In 1.173 we unified the statuses of email campaign events from email providers and renamed them to meet the industry standards and improve user experience.

In the following table you can find the naming changes:

Along with renaming, an automatic migration was carried out, in order to update event filters as defined below. The new naming along with the original one was used in the migration to ensure backwards compatibility. So don't worry, you probably don't have to update your analytics and campaigns manually, but keep an eye on your business critical use cases after the change to make sure everything works as expected.

The following change was done in all filters that use the renamed statuses:

• Operators equals have been changed to in and does not equal to not in and extended with new statuses.
• Operators in and not in have been extended with new statuses.

🚧

Rest of the string filters contains, does not contain, starts with, ends with and matches regex were not changed as they are unlikely to be used for this purpose. Manual change is needed in case you want to use those filters in combination with the renamed statuses.

For any other custom usage such as jinja or webhooks a manual change is needed as well.

Example:
equals dropped ->in [dropped, soft_bounced]

in [dropped, x, y] -> in [dropped, soft_bounced, x, y]

survey

survey happens when the customer is shown a survey question you had created. More on surveys

merge

merge when 2 customer profiles are merged into 1.

ab test

ab test happens when the customer sees one of the variants of a page, banner, or recommendation you had created in an A/B split. More on A/B testing

experiment

experiment happens when an experiment is shown to the customer. More on experiments

anonymization

anonymization happens when you remove the customer's identification but still keep their data for analytics purposes. Read more about anonymization in Individual Rights.

📘

Efficient Engagement usage

When generated, system events get processed and stored, thus counting toward your Monthly Processed Events (MPE) and Maximum Events Storage (MES) covered by your contract. Learn how to optimize your MPE and MES in this best practices article to get the most out of your Engagement experience.