Choose which events and properties to send
Send the right data upfront to avoid any blockers after Appcues is already installed
Table of Contents
The user properties, group properties, and events you send during installation control how precisely you can target experiences, personalize content, and measure results. Send the right data upfront and you won't need to pull developers back in every time you want to reach a specific audience.
User properties
User properties are attributes that describe an individual user. Send them via the Appcues.identify() call. They're the foundation for audience targeting, segmentation, and personalization.
Required
| Property | Description |
|---|---|
| User ID | A unique, non-guessable identifier for each user (e.g., a randomly generated string). Don't use names or email addresses as the ID. |
Other examples
| Property | Example value | Why it matters |
|---|---|---|
created_at |
2025-06-15T10:30:00Z |
Target by account age — show onboarding to new users, upsells to mature ones. |
first_name |
Sofia |
Personalize content (e.g., "Welcome, Sofia!"). |
email |
sofia@example.com |
Look up users in Appcues and sync with integrations. |
role |
Admin |
Show different content based on user role (admin vs. member). |
plan |
Pro |
Target upgrade prompts to free users, feature announcements to paid users. |
last_login |
2026-03-20T08:00:00Z |
Identify dormant users for re-engagement Flows. |
language / locale
|
en-US |
Deliver localized content to different segments. |
is_trial |
true |
Target trial-specific conversion Flows. |
company_name |
Acme Corp |
Useful context when reviewing individual user profiles. |
Tips
- Start with your use cases. Think about what content you want to show and to whom, then work backward to the properties you need.
- Appcues accepts strings, numbers, and booleans. Arrays are not supported.
- You can add more properties later without reinstalling.
Group (account) properties
Group properties describe the account or company a user belongs to. Send them via the Appcues.group() call. They enable account-level targeting, segmentation, and analytics.
Required
| Property | Description |
|---|---|
| Group ID | A unique identifier for the account or company the user belongs to. |
Other examples
| Property | Example value | Why it matters |
|---|---|---|
company_name |
Acme Corp |
Makes the Accounts list in Appcues easy to browse and search. |
plan / subscription_status
|
Enterprise |
Target content by plan tier — onboarding, upsells, feature gates. |
mrr |
4500 |
Segment by revenue for high-touch engagement or expansion plays. |
employee_count |
120 |
Tailor content for SMBs vs. enterprise accounts. |
renewal_date |
2026-09-01 |
Trigger renewal or retention campaigns at the right time. |
billing_interval |
annual |
Differentiate messaging for monthly vs. annual customers. |
industry |
SaaS |
Deliver industry-specific onboarding or tips. |
created_at |
2024-01-10T00:00:00Z |
Understand account maturity for time-based targeting. |
Tips
- Call
Appcues.group()afterAppcues.identify(). - Group properties apply to every user who shares the same Group ID. Use them for account-level attributes (plan, MRR) — not individual-level attributes.
- Without the group call, account-level data and analytics aren't available in Appcues.
Events
Events represent actions users take in your product. They power Goals, Experiments, audience targeting, and event-triggered experiences.
Recommended events
| Event name | Description | Use case |
|---|---|---|
Signed Up |
User creates an account | Trigger onboarding Flows |
Completed Onboarding |
User finishes setup steps | Measure onboarding success, trigger next-step content |
Invited Team Member |
User invites a colleague | Track collaboration adoption |
Created [Core Object] |
User creates the key object in your product (e.g., project, report, campaign) | Measure activation and feature adoption |
Upgraded Plan |
User moves to a higher tier | Measure conversion, trigger post-upgrade guidance |
Used [Key Feature] |
User engages with a specific feature | Drive feature adoption Goals and Experiments |
Submitted Support Ticket |
User reaches out for help | Trigger proactive in-app help |
Exported Data |
User exports a file or report | Track power-user behaviors |
Connected Integration |
User sets up a third-party integration | Measure depth of adoption |
How events are used
- Audience targeting — Show content when a user has or hasn't completed a key action.
- Event triggering — Launch an experience the moment a specific event fires (if included in your contract).
- Goals — Measure whether a Flow influenced a user to take a desired action.
- Experiments — A/B test Flows and measure which variant drives more Goal completions.
Tips
- Start with at least one event. An installation isn't considered complete without event tracking — even a single event unlocks Goals and Experiments.
- Name events clearly and consistently. Use
Created Project, notcporproj_create.
General guidance
When deciding what to send, ask two questions: "Will I want to target users based on this?" and "Will I want to trigger or filter experiences based on this action?" If either answer is yes, include it in your installation plan.
Sending more data upfront is almost always better than going back to your developer later. Properties and events that seem optional now often become essential once you start building targeted experiences.