Process Event - Liquid Tag Reference

The process_event block tag loads a CustomerEvent’s data into the template scope and marks it as handled. Use it to consume events and trigger side effects such as firing analytics calls, logging to external services, or updating customer records.

Syntax

```liquid

{% process_event event %} {% endprocess_event %} ```

Or inspect the event outside the block (read-only):

```liquid

{% if event.type == “purchase” %} {% process_event event %} {% endprocess_event %} {% endif %} ```

Property	Value
Tag Name	process_event
Type	Block tag
Source	Hydrofoil (core)

Parameters

Parameter	Type	Description
event	CustomerEvent	The event object to process. Usually an item from the current_events array.

Description

When an event is processed: 1. Inside the block, the event’s data is loaded into the template scope: type, event_data, and any related objects, such as order on a purchase event. 2. Your code can inspect and act on this data (fire analytics callbacks, log data, modify records). 3. When the block finishes, the event is marked as “handled” so it is not processed again on the next page load.

Reading events outside the block

You can read event.type and event.event_data outside the block without processing it:

```liquid

{% if event.type == “purchase” %} {# Condition matched; the event is a purchase #} {% process_event event %} {# Inside: trigger analytics callbacks #} {% endprocess_event %} {% endif %} ```

If you do not wrap the event in a process_event block, it remains unprocessed and will be offered again on the next page load.

Common event types

Event type	Triggered by	Provides
purchase	Order placed	event.event_data, order object
sign_up	Customer account created	event.event_data
password_reset_request	Password reset initiated	event.event_data
cart_abandoned	Cart left unpurchased	event.event_data
Custom events	Custom event flows	event.event_data (as defined)

For the full list and structure of event data, see Tracking Customer Activity with Events.

Examples

Fire analytics on purchase

```liquid

{% for event in current_events %} {% if event.type == “purchase” %} {% process_event event %} {% endprocess_event %} {% endif %} {% endfor %} ```

When a purchase event is encountered, order is available inside the block, and you can fire your analytics callback with order details. The tag marks the event as handled so the callback does not fire again on reload.

Log customer sign-up

```liquid

{% for event in current_events %} {% if event.type == “sign_up” %} {% process_event event %} {% endprocess_event %} {% endif %} {% endfor %} ```

Inspect event data before processing

```liquid

{% for event in current_events %} {% if event.type == “purchase” %} {% debug purchase_event: event.event_data %} {% process_event event %} {% endprocess_event %} {% endif %} {% endfor %} ```

This is useful for debugging event structure during development. The debug tag lets you inspect the event before your code acts on it.

Conditional processing by event data

```liquid

{% for event in current_events %} {% if event.type == “purchase” %} {% if event.event_data.total > 500 %} {% process_event event %} {% endprocess_event %} {% else %} {% process_event event %} {% endprocess_event %} {% endif %} {% endif %} {% endfor %} ```

Best practices

• Always process events you intend to consume. If you read an event’s data but do not wrap it in a process_event block, it fires again on the next page load, causing duplicate analytics calls or side effects.
• Check the event type first. Use an if condition outside the block to filter events by type. This avoids trying to access event-specific objects (like order) that may not exist for other event types.
• Keep processing blocks short. The block’s content should fire analytics calls or log data. Avoid heavy computation or page rendering inside it.
• Test your analytics in development. Use the debug tag to inspect event structure and confirm your analytics callback receives correct data before deploying to production.

For a complete walkthrough of the event system and use-case guidance, see Tracking Customer Activity with Events.