Clix User Management

Use this skill to help developers implement Clix user identification and user properties so campaigns can use

user.*

variables and audience filters, and so user identity is consistent across devices and sessions.

What the official docs guarantee (high-signal)

• Anonymous vs identified: if no user ID is set, Clix treats the user as anonymous; setting a user ID converts the anonymous user into an identified user and links prior activity.
• Logout: do not call

  setUserId(null)

  on logout; handle logout in app logic only; when a different user logs in, call

  setUserId(newUserId)

  to switch.
• User properties: values are strings, numbers, or booleans; user operations can throw—handle errors.

MCP-first (source of truth)

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

• clix-mcp-server:search_docs

  for conceptual behavior and logout guidance

• clix-mcp-server:search_sdk

  for exact SDK signatures per platform

If MCP tools are not available, use the bundled references:

• Contract + pitfalls →

  references/user-management-contract.md

• Logout + switching rules →

  references/logout-and-switching.md

• Property schema + PII →

  references/property-schema.md

• Implementation patterns →

  references/implementation-patterns.md

• Personalization + audience mapping →

  references/personalization-and-audience.md

• Debugging checklist →

  references/debugging.md

Workflow (copy + check off)

User management progress:
- [ ] 1) Confirm platform(s) and auth model (anonymous browsing? login? shared devices?)
- [ ] 2) Propose user plan (when setUserId/removeUserId, properties, logout policy)
- [ ] 3) Validate plan (PII, property types, logout rules)
- [ ] 4) Implement (platform-correct calls + error handling)
- [ ] 5) Verify (switching works, properties appear, campaigns can target/personalize)

1) Confirm the minimum inputs

Ask only what’s needed:

• Platform: iOS / Android / React Native / Flutter
• Auth events: where login success and logout happen in code
• User identifier: what stable ID to use (prefer internal user id, not email)
• PII policy: what must never be stored as user properties
• Campaign goals: personalization, audience filters, or both

2) Propose a “User Plan” (before touching code)

Return a compact table:

• user_id source: where it comes from (auth response, local db)
• setUserId timing: exact point (after login success / token saved)
• logout behavior: explicitly “no call to setUserId(null)”
• properties: key + type, required vs optional
• purpose: personalization / audience / analytics

3) Validate the plan (fast feedback loop)

Create

user-plan.json

in

.clix/

(recommended) or project root.

For agents: locate

scripts/validate-user-plan.sh

in the installed skill directory and run:

# From project root:
bash <skill-dir>/scripts/validate-user-plan.sh .clix/user-plan.json
# Or if in root:
bash <skill-dir>/scripts/validate-user-plan.sh user-plan.json

If validation fails: fix the plan first, then implement.

4) Implement (platform-correct)

Use MCP to fetch the exact signatures per platform, then:

• Place

  setUserId(...)

  after login/signup is confirmed.
• On logout: do nothing with Clix (no

  setUserId(null)

  ).
• When switching users: call

  setUserId(newUserId)

  after the new login succeeds.
• Set user properties only from controlled sources; avoid free-text/PII.
• Always handle errors (async calls can throw).

5) Verify

• Identity:
  • Anonymous flow works without calling

    setUserId

  • After login,

    setUserId

    is called once and stable
  • Switching accounts updates the active profile
• Properties:
  • Properties are primitives (string/number/boolean) and consistent
  • Campaign audiences can filter on them
  • Messages can use

    user.*

    personalization