Journey History

Overview

Journey histories allow you to quickly look at or query events for contacts moving through your Journeys Two journey via a log. You can look at specific events like entering a journey, which actions your customer received, when they exited the journey, etc. Histories can be helpful in analyzing your campaign success and planning future campaigns, powering BI (business intelligence) reports or troubleshooting campaign issues.

Click to view full size imageClick to view full size image

Click to view full size image

Where can I find it?

Journey history is written to Snowflake. If you don't use Snowflake, your account manager can share it through Snowflake data sharing.

What is the latency of the event data?

It takes about an hour before the journey events are loaded into Snowflake.

What is included in journey history?

Journey history automatically includes timestamps and information for all the different steps of a Journeys 2 journey, as well as entry and exit events.

What is the table name?

contact_journey_history

What does each row represent?

Each row represents a journey event for a specific contact. The possible event types are: entry, exit, action, branching split, experiment split, and blocked entry due to re-entry settings.

📘

Two entries

There will be two entries for entry steps: one indicating the initial entry of the contact into the journey, and one when the contact is transitioned to the first step of the journey.


What is journey history metadata?

These are user-configured custom context fields that are included along with action rows in journey history, very similar to data feed fields. This allows you to log any campaign or contact metadata that you're interested in accessing when querying the journey activity (e.g. contact property values, campaign metadata, product information etc.).

How do I configure metadata?

Metadata fields can be configured for action steps when setting up a journey.

Add Metadata in a Journey StepAdd Metadata in a Journey Step

Add Metadata in a Journey Step

How are the metadata fields shared and queried?

Metadata fields are shared in a json blob within the column metadata (see Table Fields below). Snowflake allows those to be queried using the syntax metadata:<field_name> (see example queries below).

{
    "cities": "Mumbai, Shanghai, Buenos Aires, Accra",
    "email": "[email protected]",
    "timezone": "Asia/Tokyo"
}

What happens if a journey history metadata field fails to render or renders empty?

A value that renders as empty is not considered a failure and will show up for that contact with an empty value. If a field fails to render, it will be loaded in the following way: <field_name>: rendering_failed. In both cases, the contact will advance to the next step in the journey.

Can I configure default metadata fields?

Yes. You can configure metadata fields under Settings > Metadata Default. Those fields are then automatically added to any new steps that are created and are required fields. They will not apply automatically to pre-existing steps.

What does the event type REENTRY_BLOCKED mean?

This means the contact qualified for the journey, but was not entered because of the re-entry criteria (frequency capping) for this journey. These events are included in the journey history to bring transparency to re-entry decisions.


Table Fields

🚧

Beta

The journey history schema is in beta and may change with little or no notice.

Column

Availability by event type

Description

EVENT_ID

All

Unique guid for each row.

EVENT_TYPE

All

The type of event. Possible values are: ENTRY, EXIT, REENTRY_BLOCKED, ACTION, BRANCHING_SPLIT, EXPERIMENT_SPLIT.

TIMESTAMP

All

Timestamp for the event.

SIMON_ID

All

Each contact that exists within Simon is assigned a unique identifier called simon_id.  This is a consistent identifier that’s managed by Simon.

ENTRY_ID

All except for REENTRY_BLOCKED

An ID for the traversal by one contact through the journey: all the steps will share this id for that contact's one traversal from exit through exit. Contacts that pass through the journey multiple times will have one entry_id for each time they do so.

JOURNEY_ID

All

Journey ID (system id for the journey, not displayed in the UI).

JOURNEY_NAME

All

Journey name

JOURNEY_VERSION_NUMBER

All

Monotonically increasing version number (starting at 1).

OPERATION_ID

All except for REENTRY_BLOCKED

A unique identifier for a contact going through that step at that time. This value is also available in personalization as simon.operation_id and is useful for tying step activity to other data sources, e.g. engagement data.

STEP_ID

All except for REENTRY_BLOCKED

Unique ID for a journey step (note: this is version-specific). (System id for the step, not displayed in the UI).

STEP_NAME

All except for REENTRY_BLOCKED

The user-configured name of the step (the builder enforces that each step has a unique name within that version).

METADATA

ACTION (if configured by user)

The user-configured fields and values for this step and contact, in a nested JSON format.

CHANNEL_ACTION_NAME

ACTION

Name of the channel action.

CHANNEL_NAME

ACTION

Name of the channel.

SKIPPED

ACTION

Boolean to indicate if contact was skipped for this step.

SKIPPED_CATEGORY

ACTION (only if skipped)

A (text-based) classification for the skip reason (e.g. ‘channel_not_deliverable’).

SKIPPED_SUB_CATEGORY

ACTION (only if skipped)

A (text-based) detailed classification of the skip reason (e.g. ‘invalid_phone_number’)

SKIPPED_DESCRIPTION

ACTION (only if skipped)

A more human-friendly description of the skip reason (e.g. 'Not deliverable to channel').

BRANCH_NAME

BRANCHING_SPLIT

The branch to which a contact was assigned in a branching split.

VARIANT_NAME

EXPERIMENT_SPLIT

The variant to which a contact was assigned in an experiment split.

LOADED_AT

All

Timestamp for when this data was loaded into Snowflake

🚧

When querying journey history across versions:

  • step_id is not stable across journey versions. All step_id’s will change between versions.
  • step_name is always unique within a journey version (whether it changes or not between versions depends on whether the user modifies it).

📘

Joining journey history data to other data sources

operation_id is available in personalization (using simon.operation_id in jinja). This makes it useful to join to other data sources, such as engagement events.

Example queries

The following are a couple example queries you can use:

// Journey history events with email
select i.email,cjh.*
from contact_journey_history cjh
left join identity_customer__latest i
on i.simon_id = cjh.simon_id
where journey_id = 27923 
order by entry_id desc, timestamp asc;
// Querying for metadata
select metadata:promo_id, count(*) 
from contact_journey_history 
where metadata:promo_id is not null
group by metadata:promo_id;

Sharing journey history using S3

In cases where sharing data through Snowflake is not an option, the journey history data can be shared via AWS S3. With this approach, Simon will export files multiple times per day containing incremental data across all journeys since the previous file. Files are in JSON format and are up to approximately 200 MB. The files always include simon_id, additional identifiers can be added as default metadata. Contact your account team to set up this export option. It will be configured at the account level and does not require any additional steps for each journey.


Did this page help you?