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

To add details from specific resources to your content instead of relying on recommendations, you can use the resource look-up merge tags. Resources can be retrieved with either a single resource lookup or by querying for multiple resources.

Specific Resource Lookup

To return an individual resource, use the resource ID. You can optionally add resource type as an additional parameter for faster lookup performance during campaign delivery.

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

This tag creates the object {{product}}and assigns the contents of the resource object to it.

If you want to populate the title of the resource in the content, use {{product.title}}.

Resource Query Parameters

Multiple Resource Query

Retrieving multiple resources without the personalization help of our Recommendations engine is done with a resources query. Here is an example of a resources tag:

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

Resources Query Parameter

To evaluate a parameter, the value must be part of the resources schema and not a property passed by the user.

bt_created_at,
bt_updated_at

Points to Remember

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

• Operator names should be in uppercase. In this example, use 'CONTAINS' instead of 'contains'

• 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.

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.
	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 below 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 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:

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

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.

{% 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