User Identity
Attach a known user id to Digia Engage's own analytics and survey submissions — Digia.setUserId after login, Digia.clearUserId on logout.
By default, Digia Engage attributes everything it records — impressions, clicks, dismissals, and survey submissions — to an anonymous device id. Digia.setUserId ties those events to a known user id from your app, so Digia's data lines up with the user you already identify elsewhere. Digia.clearUserId returns to anonymous, for logout.
1. What it affects
Setting a user id changes how Digia attributes what it records — it does not change which campaigns fire:
Analytics — impressions, clicks and dismissals are recorded against the user id.
Survey submissions — responses are stamped with the user id, so results tie back to a known user instead of an anonymous device.
Session — setting or clearing the id starts a fresh analytics session.
Delivery is decided by a campaign's trigger (and, when present, by your CEP) — never by the id you set here. Treat this as attribution, not targeting or segmentation.
2. Identify a user after login
Call setUserId once you know who the user is — typically right after login, and after Digia.initialize has run. Use the same id your backend and analytics already know the user by, so Digia's data joins cleanly with the rest of your stack.
Digia.setUserId('user-123');Digia.setUserId("user-123")Digia.setUserId("user-123")await Digia.setUserId('user-123');3. Clear on logout
Call clearUserId when the user logs out. Subsequent events return to the anonymous device id under a new session.
4. Alongside a CEP
When a CEP (CleverTap, MoEngage, WebEngage) drives delivery, you already identify the user to that platform with its own login call — and that call governs the CEP's targeting. It does not reach Digia's analytics. Call Digia.setUserId alongside it so Digia's own impression, click, dismissal and survey data carry the same id, and the two line up.
Last updated