Personalization often hinges on a cookie value
An A/B test bucket flag. A "seen the welcome modal" flag. A language preference. A referral-source cookie from a marketing campaign. All stored in the user's browser, all trivially readable in JavaScript — but unreachable from PHP-based automations that run on the server.
If a macro needs to behave differently based on a cookie, you need a way to bring that cookie into the server-side context.
What most people do instead
$_COOKIE in a custom pluginRequires PHP. The cookie check becomes a snippet scattered across your theme.A better way: one command, cookie as chain result
Run get user cookie -name=cookie_name inside a macro. Get back step1.exists (boolean) and step1.value (the cookie's value). Use them in branch conditions or as inputs to downstream steps.
Branch a macro on cookie values. Step 1 reads the cookie. Step 2 branches on step1.value: if "variant_a", send template A; if "variant_b", send template B; if not set, send fallback. Real-time personalization from one macro.
How it works
Reads $_COOKIE[name] from the current HTTP request. If the cookie is present, returns exists=true and value=<string>. If not, returns exists=false. Downstream macro steps can reference both.
-name=cookie_namestep1.exists, step1.value| Parameter | Value |
|---|---|
-name(required) | Cookie name (e.g., ab_test_bucket) |
| Returns | exists (boolean), value (string) |
| Scope | Current HTTP request only — no cross-user reads |
| Can be used in |
Real example
You run an A/B test on pricing pages. A JavaScript snippet assigns each visitor to "variant_a" or "variant_b" and stores it in a cookie. When the visitor requests a quote, you want different email templates per variant.
The macro triggers on quote request. Step 1: get user cookie -name=ab_test_bucket. Step 2 branches: if step1.value == "variant_a", send "Template A"; else send "Template B". Your variants stay testable without touching your email flows.