Clix Personalization

Use this skill to help developers write personalized Clix campaigns using template-based variables and light logic in:

Message content (title, body, subtitle)
Links (dynamic URL or deep link params)
Audience targeting (conditional include/exclude rules)

What the official docs guarantee (high-signal)

Data namespaces:
- user.* (user traits/properties)
- event.* (event payload properties)
- trigger.* (custom properties passed via API-trigger)
- Device/system vars: device.id, device.platform, device.locale, device.language, device.timezone, plus user.id, event.name
Missing variables render as an empty string.
Output: print values with {{ ... }}.
Conditionals: {% if %}, {% else %}, {% endif %} with operators == != > < >= <= and or not. Invalid conditions evaluate to false.
Loops: {% for x in y %} / {% endfor %} (use guards for empty lists).
Filters: upcase, downcase, capitalize, default, join, split, escape, strip, replace (chain with |).
Errors: template rendering errors show up in Message Logs.

MCP-first (source of truth)

If the Clix MCP tools are available, treat them as the source of truth:

clix-mcp-server:search_docs for personalization behavior and supported syntax

If MCP tools are not available, use the bundled references in references/.

Workflow (copy + check off)

Personalization progress:
- [ ] 1) Identify where the template runs (message / URL / audience rule)
- [ ] 2) Identify trigger type (event-triggered vs API-triggered)
- [ ] 3) Confirm available inputs (user.*, event.*, trigger.*, device.*)
- [ ] 4) Draft templates with guards/defaults
- [ ] 5) Validate template structure (balance tags, avoid missing vars)
- [ ] 6) Verify in Clix (preview/test payloads, check Message Logs)

1) Confirm the minimum inputs

Ask only what’s needed:

Where used: title/body/subtitle vs URL/deep link vs audience targeting rule
Campaign trigger:
- Event-triggered → event.* is available
- API-triggered → trigger.* is available
Inputs:
- Which user.* properties are set by the app
- Which event.* / trigger.* properties are passed (include example payload)
Fallback policy: what to show when data is missing (default strings, guards)

2) Produce a “Template Plan” (before tweaking lots of templates)

Return a compact table the user can approve:

field (title/body/url/audience)
template (Liquid)
required variables (and their source: user/event/trigger/device)
fallbacks (default filter and/or conditional guards)
example payload + expected rendered output

3) Authoring guidelines (what to do by default)

Prefer simple variables + default over complex branching.
Add guards for optional data and for arrays (size > 0) before looping.
Prefer pre-formatted properties from your app (e.g., "7.4 miles", "38m 40s") instead of formatting inside templates.
Keep logic minimal; complex branching belongs in the app or segmentation setup.

4) Validation (fast feedback loop)

If you have a template file (recommended for review), run:

bash <skill-dir>/scripts/validate-template.sh path/to/template.liquid

This script does lightweight checks (matching {% if %}/{% endif %}, {% for %}/{% endfor %}, and brace balancing). It can’t guarantee the variables exist — you still need a payload + console verification.

5) Verification checklist

Missing data: does the template still read well with empty strings?
Trigger type: API triggers use trigger.* (not event.*).
Message Logs: check rendering errors and fix syntax issues first.
Upstream data:
- If user.* is missing → fix user property setting (see clix-user-management)
- If event.* is missing → fix event tracking payload (see clix-event-tracking)

Progressive Disclosure

Level 1: This SKILL.md (always loaded)
Level 2: references/ (load when writing/debugging templates)
Level 3: scripts/ (execute directly, do not load into context)

References

references/template-syntax.md - Variables, output, conditionals, loops, filters
references/common-patterns.md - Copy/paste patterns for messages + URLs + guards
references/debugging.md - Troubleshooting missing variables and Message Logs