Hold-until event vs hold-until property change: wait for a behavior fire vs wait for a profile field flip

Hold-until-event releases when a tracked behavior fires after the person enters the hold (Rules Met) or times out (Rules Not Met; hard max often ≤30 days). Hold-until-property-change releases when a profile attribute is added/updated after entry. Both typically see only changes after the hold starts, not history before entry.

What is the difference between hold-until event and hold-until property change?

Both are mid-journey waits; they differ in the release signal:

• Hold-until-event: wait for a behavior fire—purchase, signup_completed, app_opened.
• Hold-until-property-change: wait for a field flip—birthday filled, city set, onboarding_step 1→2.

Shared rule: after-entry-only. A purchase or birthday that existed before hold entry usually will not release that hold unless you also evaluate at entry.

Close to time-capped vs indefinite wait-until and wait until event vs fixed delay; here the focus is event vs field change.

How each works

Hold-until-event

Enter → listen for named events → Met or Not Met at cap. Best when truth lives in the behavior stream.

Hold-until-property-change

Enter → listen for attribute add/update → Met or timeout. Best when truth lands from a form, popup, or CRM sync onto a field—not always a clean event name.

Iran examples

Ecommerce — wait for purchase vs wait for city

Event: after signup, hold for order_completed up to 14 days; Met → post-purchase; Not Met → shipping-to-provinces education.

Property: hold until shipping_city is filled from popup/form; Met → delivery-estimate SMS; Not Met → “complete your city” email.

SaaS — activation vs profile step

Event: integration_connected. Property: onboarding_step >= 3.

Fitness club — attendance vs birthday

Event: class_checked_in. Property: birthday from membership form.

When to choose which

1. Signal arrives as an analytics/SDK event → Event hold.
2. Signal lands as a profile field from form/CRM → Property hold.
3. Always set a cap and Not Met creative.
4. If the goal is “leave the whole journey,” exit on conversion vs global exit criteria may beat a hold.
5. Do not claim Hold-for-Reply on SMS unless inbound SMS truly exists.

Leadara mapping

• Events: stable names for purchase/signup/open.
• Profile properties + popups/forms: write completion into properties.
• Journeys: wait-until event or wait-for-property-change with a cap.
• Email / SMS: Met = success path; Not Met = completion or alternate offer (Kavenegar/Nikaline).
• Live Chat: human help for form confusion; AI Chat internal only.

Common mistakes

• Expecting the hold to see pre-entry purchases.
• 30-day caps with empty Not Met creative.
• Property holds on fields a nightly job rewrites.
• Infinite holds instead of goal exits.
• Mixing event names and property names in the brief.

One-line takeaway

Event hold = wait for a post-entry behavior fire; Property hold = wait for a post-entry field flip—both with a cap.

Next step

Open one live hold. Ask: event or field? Did they already have the signal before entry? Write cap + Not Met.

FAQ

Does the hold see events before entry?

Usually no—after-entry-only. Use entry filters/segments for history.

What is the maximum hold duration?

Many systems hard-cap near 30 days; in Leadara lock duration to product reality—do not leave infinite.

When is an exit better than a hold?

When the outcome should end the whole path, not continue inside it.

What if a property flips true→false→true?

Define whether any update counts or only empty→value / specific transition.

Can I OR event and property?

If the UI allows; otherwise two holds or an explicit combined condition.

Does Not Met mean the user failed?

No—your wait budget ended. Avoid punitive copy.

Popup that does not write the property?

Property hold never Mets. Fix the data pipe first.

Step-by-step

1. One-sentence signal.
2. Event or field?
3. Lock the cap.
4. Draft Met vs Not Met separately.
5. Test pre-entry signal, post-entry signal, never.
6. Watch Met/Not Met share for two weeks.

Metrics

• Met vs Not Met share
• Median time-in-hold
• Field completion after nudge
• Unwanted exits while holding

PM language

Say “14-day purchase hold: 41% Met, 59% Not Met→city education,” not “users are slow.”

Sketch

enter hold(mode, signal, cap):
  start = now()
  loop:
    if mode==event and event_after(start, signal): advance(met); return
    if mode==prop and prop_changed_after(start, signal): advance(met); return
    if now()-start >= cap: advance(not_met); return

Acceptance tests

1. Pre-entry event does not release (unless designed otherwise).
2. Post-entry event → Met.
3. Post-entry field change → Met in property mode.
4. No signal to cap → Not Met with correct creative.
5. Purchase exit still works while holding.

Channel checklist

• Not Met SMS short and useful?
• Met email success tone, not urgency spam?
• Does the popup actually write the property?

Hold vs entry filters

Entry filters decide whether someone starts. Holds decide when they continue. Put already-purchased users in entry logic; use holds for future purchases.

Data note for engineering

If CRM touches every profile nightly, naive property-change holds false-fire. Require meaningful change (new ≠ old, or empty→value), not every write.

Vignette: incomplete profiles in Iranian ecommerce

Many stores collect phone at checkout but city later via popup. Property hold on shipping_city with a 7-day Not Met path to a light SMS beats blasting everyone a shipping promo on day 0. Event hold on order_completed stays separate so browsers who never buy do not sit in a purchase wait forever without a cap.

Incomplete-profile vignette (Iran ecommerce)

Many stores collect phone at checkout and city later via popup. Property hold on shipping_city with a 7-day Not Met SMS beats day-0 shipping promos to everyone. Keep purchase event holds separate so non-buyers are not parked forever without a cap.

Popups and gamification in Leadara

If a popup or gamification writes the field, name that property in the hold. If you only get a game_completed event and the field stays empty, use an Event hold on that event—not a Property hold on a blank field.

QA matrix to paste in the ticket

Quick chooser

Product briefing mistake

Do not write “wait until profile complete” without naming the field, the writer (form/CRM), the cap, and Not Met copy. Vague briefs create vague holds.

Re-entry note

If Not Met sends a nudge and the user later completes the field, decide whether they may re-enter the Met path. Document once-only vs cooldown to avoid “give-up email then success email” pairs.

Related reading

• Wait-until-conditions time-capped vs indefinite: proceed when met or when the timer expires
• Wait until event vs fixed delay: pause for a signal vs pause for a clock
• Exit on conversion vs global exit criteria: goal kill-switch vs property/behavior eject