.svg?fit=max&auto=format&n=mBaWmVpTOpDBIB6_&q=85&s=36c7989ebe591de9ac7d3618f0a04a28)
.svg?fit=max&auto=format&n=mBaWmVpTOpDBIB6_&q=85&s=5afe473ba3ef2469d3e839045bcb099c)
usage_view.threshold_crossed) fires the first time a store’s value for one of your usage views reaches a number you set. Where Custom event is tracked reacts to an event, this one reacts to the total: “this store’s GMV just passed 10,000 this billing period”. It carries the event that took it there too, so a milestone email can print both.
Configuring it
Two settings, and both are required:- Usage view: which view to read. The editor prints the view’s definition and window under the picker, because “crosses 10,000” means nothing until you know whether the figure resets every billing period or counts everything ever reported.
- Threshold: an absolute number, in the view’s own unit. 10,000 of
properties.total_priceis 10,000 of whatever currency your app sends.
The threshold is an absolute value, not a percentage of a plan’s included quantity. Pricing a view is plan terms; this trigger is about the figure itself.
When it fires
On the transition, and only upward. Meridian evaluates the view when your app tracks an event that moves it: if the store’s value goes from below the threshold to at or above it, the flow runs for that store. Everything follows from that:- A store already above the number when you create the automation does not fire. It never transitions across the line; the next store to reach it does.
- Lowering the threshold later does not fire for the stores already past the new number, for the same reason.
- An event your view skips (a total over an event property the event didn’t carry) moves nothing, so it can’t cross anything.
- An event dated outside the view’s current window moves nothing either. An order your app dated in September does not count toward an October month-to-date view, nor toward a billing-period view once that period has rolled over, so it cannot take either across a threshold. An all-time view has no window edge, so every event moves it.
Once per store, per window
A busy store can cross a threshold and then keep going. The flow runs once, and when it may run again depends on the view’s window:
A value can fall for two reasons: a negative contribution (a refund summed into a total), or, on a rolling window, events sliding out of it. Either way the re-arm is noticed at the next event that moves the view. Nothing is evaluated on a schedule.
Two automations watching the same view are two independent promises: each gets its own run.
Live usage only
A threshold is only ever tested on live ingestion: atrack() call that recorded a new event. Recomputing a view, backfilling its history, or re-seeding its counters rewrites the very numbers this trigger reads, and none of them send anything. An SDK retry of the same call (same idempotency key) doesn’t either: it records no new event.
This is deliberate. A recompute can take thousands of stores from below a threshold to above it at once, for data that is months old. That is a maintenance operation, not ten thousand milestones.
An event your app dated more than 24 hours before Meridian received it is a backfill sent through the live call, and it is treated like one: it is recorded, it moves the view, and it is never tested against a threshold. It becomes part of where the store stood before the next live event, which is then measured correctly. So a store whose replayed history already takes it past 10,000 gets no milestone for it, and its next live order does not cross anything either, because the store was already above the line. The cost: a milestone reached only by events that arrive more than 24 hours late is never sent.
In a batch that mixes the two, only the recent events inside the view’s window count toward the crossing, and the event the flow carries is always one of them.
What it carries
The store’s variables, plus the crossing itself:
On an
all_time view the two bounds are absent (the window is unbounded), so they render as nothing and satisfy only is empty in a condition.
The event that crossed
The trigger also carries the event that took the view over the line, under the same names Custom event is tracked uses:
So “your 1000th order” can name the order:
Which event, when a batch crosses
A batch is still one transition, so one event out of it is the one the flow carries, and it is the exact one: Meridian walks the batch in the order your app sent it, starting from the store’s value before the call, and carries the event at which the running total reached the threshold. So a store on 0 orders that reports three in onetrackMany call crosses a threshold of 1 on the first of them, and a “first order” email is about the first order.
This is decided per automation, not per batch, because the number is the automation’s. Two flows on the same view, one at 1 and one at 100, fed by a single call that takes a store from 0 to 150, run once each and carry a different order: the 1st and the 100th.
An event the view skips counted nothing, so it is never carried and never counted on the way. Landing exactly on the threshold counts as reaching it, the same at or above test that decides whether the flow runs at all.
For a single track() call, which is the ordinary case, there is nothing to choose: that event is the one.
Building on it
- Congratulate a store on its first 10,000 of processed GMV, once per cycle.
- Send a “first order” email on a count view with a threshold of 1, printing the order itself from its
properties.. The tracked trigger cannot express “first”, because it has no variable for the store’s running count. - Warn a store approaching a limit your app enforces itself, before it hits it.
- Write the reading itself into a custom field (the action can store
usage_view_valuerather than a fixed marker), so segments and reports can work off the number, and let your sales follow-up run from there.