# Overview

An event property is datum about a specific event that filtered a customer into a segment. Reference this data to personalize your messaging to your customer. See [Use contact event content](🔗) for more information on how to do that.

Event Properties don't display in a customer's context table by default.

See [How to display event properties](🔗) below.

# View event properties

Event properties don't display by default. To display them, you have to [either link a lookup table or load full event table data.](🔗). If you've already done this, you can view event properties from anywhere you can set dynamic content.

# Understand event properties

Within the customer's event properties, you'll see two columns: **Key** and **Value**.

## Key

This is the field name in a dataset. At minimum, the syntax has three parts:

  1. `table name`

  2. `index`

  3. `column name`


Field name

  • Any name with that goes beyond three parts is in a linked lookup table. See [Link a lookup table to a contact event](🔗) below for more detail on why and how to link these tables.

  • If you see just three parts, like above, this datum is from the _event itself_.

## Value

This contains the respective datum associated with the `key`.

For example, the `created_at` `key` might include a `value` of `March 12, 2020` (as it does in the example below).

## Example

Here's one example of a linked lookup table giving us details on the price item a customer purchased that we can now use to personalize a follow up message to them:


Event properties

In the example above, the content provided is actually looking up the `product_id` from this event in our corresponding linked lookup table and then joining that value onto our event for easy use in content.

This is giving us the **sku/image/name/price** of the **product** (from our lookup table) that is identified by _this_ event's `product_id`. Now, you can use detailed properties from a lookup table (like the prices and images of a product) by joining between a _purchase event_ and a _lookup table_.

# How to display event properties

_Event Properties don't display in a customer's context table by default._ To display these properties, you must do either of the following when building a template with an event-based segment:

  • [Link a lookup table to the contact event table(s)](🔗) underlying the segment for basic content.

  • [Load the entire Contact Event table(s)](🔗) for full event content.

Should I use a Linked Lookup or Full Event Content?

Linked lookups are the best route to take when you have content that is not specific to the event itself, such as a product name or image. For example, say you have a customer who ordered recently. You know the product SKUs they ordered, but you'd like to also include the specific product name and image. You can use a linked lookup to access all that data together based on the SKU: their name, recent purchase, image, etc.

Full event content is good for a holistic view of events. For example, check-in and checkout dates for a specific search can't be accessed via linked lookups because this data is unique to the customer and their search.

## Link a lookup to a contact event table

  1. Navigate to the [contact event dataset](🔗) you want to use in this segment.

  2. Click the **dataset editor**.

  3. Configure a [linked lookup](🔗). (Refer to [Lookup tables](🔗) for additional context.)

### Lookup Fields that are Sets

You may have a linked lookup field that is a **set** (ie. a list of multiple values). Purchases are a common example of this. If it's possible for a purchase to have more than one `product_id` associated with it then you need to format these product IDs as a **set field**. This is ingested by Simon as a comma-delimited string like so: `"product_id_1,product_id_2,product_id_3"`.

Content for set fields requires its own syntax. You must write a [loop](🔗) to iterate over the set values:


Jinja for accessing lookup table properties for multiple product IDs using a set event property

First, on line 5, we must split our set field (`product_ids_set`) so that we can use each `product_id` value individually. By looping over the `product_id`s we can then look them up in our `product_catalog` individually to access the corresponding lookup values.

Then you must specify the lookup fields you'd like to use for content. A lookup has the following format:

## Full Event Content

Full event table data should be loaded into Simon as content, on an as needed basis. If you find that there's an event property that you've defined in your contact event table dataset that you need for custom content and _can't_ access through a linked lookup, you have the option to "load" all of the event context for use in custom content. **This process takes time**, but it can be kicked off manually through the `CONTACTS` context table.

Should you want to do this for a segment whose event tables have properties you want to access, you can filter the table on `Event Properties`. At this point, if your contact event table has not yet been loaded, you should see a message box that you can click to expand. Follow the instructions to load your dataset.


# Event properties not displaying?

Event properties won't appear at all if you're not looking at an event-based segment _or_ if your event-based segment has zero contacts.

If you're using an even-based segment, see [How to display event properties](🔗) above.