Look-Ups

Lookups in applications are used to represent a set of codes and their translated meanings. Let’s have a look at the available lookup tags within ZML:

Resource Look-Ups

Within ZML, resource look-ups allow you to fetch and display catalog/resource data directly in content. Resources can be retrieved using:

A single resource lookup
A multiple resource query

Specific Resource Lookup

To return an individual resource, use the resource ID. Optionally include resource_type for improved performance.

CODE

{% resource product
  | id: sku
  | resource_type: 'item'
 %}

This creates the object {{product}}, which contains the resource data.

Example usage:

CODE

{{product.title}}

Parameters	Description
id	Specify the resource identifier you’re trying to retrieve.
resource_type	Specify the type of resource.

Multiple Resource Query

To retrieve multiple resources without recommendations, use the {% resources %} tag.

CODE

{% resources products
| count: 3
| filter: 'resource-type', '=', 'article|product'
| filter: 'pubDate', 'AFTER', '-P1D'
| filter: 'category', 'CONTAINS', 'baseball'
| sort_field: 'start_date'
| sort_order: 'asc'
%}

Filter fields must exist in the resource schema. User-passed properties are not valid.

Parameters	Description
count	Specify the number of resources to be returned in your query.
filter	The one or more resource fields to query against.
sort_field	The timestamp field to sort the returned array on. No other data type is supported. CODE `bt_created_at, bt_updated_at`
sort_order	The order in which the array of resources will be returned. `asc` or `desc`

Filter Operators (Liquid `{% resources %}`)

Operator	Description	Typical field types/notes
`=`	Exact match: the field must equal one of the supplied values (see pipe below).	TEXT, TAGSET, resource-type, identifiers; also used where the schema treats values as exact.
`CONTAINS`	Value must appear as a substring (or overlap match, depending on backend), not necessarily exact equality.	TEXT, string-like props, TAGSET-style lists where “contains” semantics apply.
`AFTER`	Timestamp on the field is after the reference time described by the value (commonly a relative ISO-8601 duration from “now”).	DATE / TIMESTAMP fields (e.g. `pubDate`, or system fields like `bt_created_at` / `bt_updated_at`, which may map to internal `@created_at` / `@updated_at`).
`BEFORE`	Timestamp on the field is before that same kind of reference.	Same as AFTER — date/timestamp fields.
`NOT`	Exclude resources that would match the given value(s) for that field (negated condition).	Same families as `=` / `CONTAINS` depending on how the service applies NOT to the field.
`EXISTS`	Filter on whether the field is present or absent (or the documented sentinels), not on a specific content match.	Per product grammar, the value should be `true`, `false`, or empty; applies to fields where existence is meaningful (TEXT, TAGSET, FLAG, etc.).

Operator Rules

CODE

{% resources my_product
| count: 3
| filter: 'resource-type', 'CONTAINS', 'product'
| sort_field: 'bt_updated_at'
| sort_order: 'desc'
%}

Operators must be uppercase.
- In this example, use 'CONTAINS' instead of 'contains'
If omitted, the operator defaults to =
Variable names should be unique and differentiated from other variables and values within the tag.
- In this example, since ‘product’ is used as a value, do not use that as a variable name elsewhere.
v=Variable names should not conflict with property names that may be available on the profile.
Use only schema-defined fields.

Resources	Resources, also known as feeds/catalogs, are product listings of a client’s domain, like e-commerce, arts, banking, and more. This list is synced to ZMP daily.
Variants	Variants are sub-products or child nodes of the same product.
Variants	Default Product	Variant Product: (Blue Highlight)

ZMP will result in only very few products in the resources' graphical UI. So, to identify and analyze all the data available in resources, we are using the following liquid syntax as a solution:

Results in Resources UI

Resource Lookup Syntax

CODE

{% resource product | id: "9097" | resource_type: "product" %}
<br>product=>{{product}}}<br>

Resource with Variant Lookup Syntax

CODE

{% resource product | id: "9097" | resource_type: "product" %}
{% assign get_v_p = product["variants"]["100083508"] %}
<br>Variant=>{{get_v_p}}<br>

Event Look-Ups

Trigger Event Object

For content being sent from a triggered campaign, an event object is available to populate information in the content from the event that triggered the campaign. The properties available in the event are the same properties passed in the payload of the event. Take the following purchased event as an example:

Purchased Event Payload

{

"session": "afb35e24-37a9-40b4-96e5-7eb937c064e5",

"last_purchased":

{ "items": [

{

"productsku": "J9834RHJ",

"productname": "Some Cool Pants",

"quantity": 1,

"price": 45.68

}

],

"total": 45.68,

"cartuserdata": {

"first_name": "Ryan",

"last_name": "Malone",

"email": "rmalone@zetaglobal.com"

}

To populate the productname information from the first item in this purchased event, we can use the following event object:

Input

You bought: {{event.purchased.last_purchased.items[0].productname}}

Output

You bought: Some Cool Pants

Event Look-Up Tag

Multiple past events can also be used in content using an event lookup tag.

The following example creates a variable called purchases as an array of the last three purchase events for the given user_id, the message is being created for. The full contents of the array can be viewed in content using {{purchases}} or a for loop to iterate over the array to find the details you need.

Note that ZMP system events are disabled by default from event look-ups. If you need to access a ZMP system event, please reach out to your Zeta account team.

Input

CODE

{% event purchases | event_type: 'purchase' | count: 3 %}
{% for purchase in purchases %}
    {{purchase}}<br/>
{% endfor %}

The event_type parameter can be changed to retrieve events of the specified name. The count parameter sets the limit for the number of past events that should be retrieved.

Event Lookup Tag Query Parameters

Parameters	Description
event_type	The exact name of the account event to look up.
count	Specify the number of past events to be retrieved.

Resource Look-Ups

Specific Resource Lookup

Multiple Resource Query

Filter Operators (Liquid {% resources %})

Event Look-Ups

Trigger Event Object

Event Look-Up Tag

Event Lookup Tag Query Parameters

Filter Operators (Liquid `{% resources %}`)