Build a Basic Any-Order Query

Configure your Event Sources and create the User Defined Events you want to analyze.

3 min readProduct documentationzinzu Any-Order Behavior User Guide

Before You Begin

Events can come from different tables or views. Their EventOwner values must identify the same entity across sources.

Example: Identity checks use APPLICATION_ID, while consent records use REQUEST_ID. Both must contain the same application identifier for zinzu to combine their records.

Build the Query

Expand Journey Builder and select Any Order Behavior.
Enter a descriptive query name.
Drag the required User Defined Events into the event basket, or use their add buttons.
Leave the system filter basket empty for a basic query.
Click Submit Query to review the execution settings.

Example name:Applications with all verification actions

Event basket:Identity Verified + Address Verified + Consent Received

Applications with all verification actions. Illustration: Application-verification query with three events and no system filters. — Illustration: Application-verification query with three events and no system filters.

How It Works

zinzu examines each EventOwner’s records chronologically and collects records matching the required events. Unmatched records are skipped—they do not interrupt the match or fill a required event occurrence.

Example: Your query requires Identity Verified + Address Verified + Consent Received.

An application’s timeline contains:

Consent Received — collected.
Profile Updated — skipped.
Identity Verified — collected.
Email Sent — skipped.
Address Verified — collected; the set is complete.

The three required actions match even though they occurred in a different order and had unrelated activity between them. You do not need an Any (wildcard) control.

Collect required events and skip unrelated records. Documentation illustration based on the supplied guide and native UI components. Not a live query execution. — Illustration: Collect required events and skip unrelated records.

Without system filters or negation, the set completes as soon as every required occurrence matches. zinzu then starts collecting another set from later records. Records from a completed set are not reused to create overlapping combinations.

Additional records for an already-matched event are normally skipped unless another copy or a Recurring filter makes them relevant.

Note:Skipped records still count toward the sequence record limit. Timing filters use the matched records’ timestamps, so time spent between those records still affects the measured duration.

When to Use It

Application verificationFind applications with Identity Verified + Address Verified + Consent Received, regardless of their order or other activity between them.

Applications with all verification actions. Documentation illustration based on the supplied guide and native UI components. Not a live query execution. — Illustration: Applications with all verification actions.

Feature adoptionFind users who performed Report Created + Dashboard Opened + Export Used, even across visits with other actions in between.

Feature adoption. Documentation illustration based on the supplied guide and native UI components. Not a live query execution. — Illustration: Feature adoption.

Operational checksFind orders with Inventory Checked + Payment Authorized + Address Validated, regardless of which check happened first.

Operational checks. Documentation illustration based on the supplied guide and native UI components. Not a live query execution. — Illustration: Operational checks.

These examples require the actions to occur, without enforcing their order.

Continue readingMultiple occurrences