Brief your developer before install
Turn what you want to launch into the data your developer needs to send.
Table of Contents
Appcues can only target on the data you send it. Decide what to send before your developer writes any code, and you get a working install in one pass instead of asking them back every time you want to reach a specific audience.
This is your installation plan, for web, mobile, or both. You don't need to know your codebase to fill it in. Start from what you want to launch, and the data requirements fall out of that.
Its companion page, Install Appcues without rework, is what your developer reads. Send it with the finished plan.
Also known as: installation plan, implementation plan, install brief.
How to use this
Make a copy of the installation plan template and keep it open while you read. This page explains what goes in each tab and why; the template is where you write it down.
Work through steps 1 to 5, then send the filled-in template to whoever is installing. They pair it with Install Appcues without rework, which covers the code.
Fill it in with your developer in the room if you can. Twenty minutes together beats three rounds of email.
Step 1: Name the first three things you want to launch
Not everything you'll ever build. The first three. Write each one as a sentence describing who sees it and when.
Pick from the patterns below, which are the ones most teams start with.
| What you want to launch | Data it needs |
|---|---|
| Orient brand-new users in their first session | Signup date |
| Group first-week setup into a trackable list | One event per setup step |
| Nudge users who signed up but haven't done the key action yet | Signup date, activation event |
| Guide the person doing configuration, not everyone | Role or permission level |
| Promote a feature only to plans that have it | Plan tier |
| Prompt an upgrade when a free account hits a paid feature | Plan tier, feature-usage event |
| Give new accounts a resource hub for their first few months | Signup date |
| Re-engage accounts that have gone quiet | Last active date |
| Ask for NPS once users are established, not on day one | Signup date or activation event |
| Onboard a whole account, not just the person who signed up | Account ID, account plan tier |
Write yours on the Launches tab, one sentence per row, and note whether each one is web, mobile, or both. For each one, also answer this: how will you know it worked, and what does the user do that proves it?
A useful prompt if you're stuck. List every discrete step a user has to complete before you'd call them fully onboarded. "Uses the product" isn't a step. Push until you have the granular sequence, then give each step its own experience rather than collapsing them into one long Flow.
Step 2: Derive the data from those sentences
Each sentence names the data behind it. Work through one at a time.
Take this example:
Show an upgrade prompt to free-plan admins who signed up more than 30 days ago and still haven't created a project.
That sentence needs three user properties and one event:
| From the sentence | What it becomes |
|---|---|
| "free-plan" |
planTier property |
| "admins" |
role property |
| "signed up more than 30 days ago" |
createdAt property |
| "created a project" |
Created Project event |
Do the same for your three, then write the results onto the User properties, Account properties, and Events tabs. Duplicates are fine, so list each item once.
Use User properties for anything describing an individual person, and Account properties for attributes shared by everyone in the same company or team. Skip that one if your product has no accounts. Events are things a user does.
On each property row, fill in the name, what you'll use it for, and the source. Leave the key, type, and example value columns for your developer.
Source matters more than it looks. A property can arrive from your install, from an integration like HubSpot or Salesforce, or from the API. Integration properties sync periodically rather than on every identify call, so anything that has to be current the moment a user loads a page belongs in the install.
If you're installing on mobile, you also need a screen list. Your developer adds a screen() call that reports which screen the user is on, and targeting depends on it, so name the screens your launches happen on. Use the Screens & containers tab, which also covers deep links and the containers mobile Embeds render into.
Four notes before you finalize the list.
Sending more now is cheaper than adding it later. A property that looks optional today is usually the one blocking a campaign next quarter, and each addition means another request to engineering.
You don't need a developer for every event. Anyone can create events by clicking elements in the Appcues Builder, and those events include matching past activity from the date your account started recording. Reserve the developer-written events for things that need validation before they count, like a payment succeeding.
You need events for measuring, not only for targeting. These are usually different events. "Hasn't created a project" is targeting. "Placed an order" is measurement. When you set a campaign's objective, the thing it measures has to be built on an event your product already sends, so if nobody sends it the campaign has nothing to report. Depending on your instance that measure becomes a Key Moment or a Goal, and either way it needs the event behind it. Naming your success measure now gets that event into the install instead of into a follow-up request.
Your developer maps each item to a real field. Leave the field names and data types to them. Your job is naming what you need and why.
Step 3: Fill in the account details
Only you can answer these, and a missing answer here stalls the install. They live on the Start here tab.
| Item | Where to find it |
|---|---|
| Appcues Account ID | Settings > Account ID |
| App ID for each mobile app | Settings > Apps & Installation |
| Data hosting region, US or EU | Ask whoever set up your Appcues account |
| Web domains for staging and production | Your team |
| Mobile app names, per environment | Your team |
| Which mobile frameworks you use | Your developer |
| Who to ask when the developer has a question | You |
| Who owns your Content Security Policy | Often a different team from the one installing |
Data hosting is not the same as where you are based. The US or EU answer is about which Appcues environment holds your data, and it is set when the account is created. Being a European company does not mean your account is on EU hosting. If nobody is sure, ask before your developer starts, because it changes the host the SDK loads from.
Two dates, not one. The template asks when the install is complete and, separately, when you go live with content. They are rarely the same week. For mobile, ask your mobile team which release the install will land in before you promise a date internally.
Which other systems must match Appcues. If you plan to connect Salesforce, HubSpot, Segment, Amplitude, Mixpanel, or a data warehouse, say so now. Most of those require the Appcues user ID to match a value that already exists in the other system, and changing it afterwards splits every user profile in two. Note each tool on the Integrations tab, along with whether you need data flowing in, out, or both.
Whether you need identity verification. This signs your identify calls so only users you vouch for can receive Appcues content. It needs backend work and usually a security review. Ask your security team now rather than discovering the requirement after launch.
Who to exclude. Every unique identified user in a rolling 30-day window counts toward your MAU total, whether or not they see anything. Internal staff, test accounts, QA sessions, and support impersonation are the usual candidates.
Step 4: Name what Appcues will point at
Skip this and you will be back asking for developer time within a month.
Appcues content attaches to your interface. On web that means a CSS selector; on mobile it means a recognizable element, and a container for anything embedded in a screen. When the thing it attaches to changes, your content stops appearing and nothing warns anybody.
You don't need to map your whole product. List the elements involved in the three launches from step 1 on the Targeting readiness tab: the buttons, nav items, and cards your content will attach to, and for mobile, the screens where you want an Embed. Your developer adds a stable attribute to each one while they are already in that code.
Ask them to confirm two things before they start:
- Which field they'll use as the user ID. It has to be unique and stay the same for the life of the account. They can use whatever value they prefer, though an opaque one like a UUID is the better default, because it doesn't change when a user updates their details.
- That the selector check is going into their review process. Before shipping a frontend change, they can ask Appcues AI or the Appcues MCP server whether Appcues depends on what they're changing. That habit is what keeps your content working after a redesign.
Step 5: Send it over
Send the filled-in template along with Install Appcues without rework. Between them your developer has the what and the how, and the Install checklist tab gives them somewhere to mark off progress you can see.
Keep it current
Treat the template as a living document rather than a one-off. When someone adds a property or an event, it goes there first. When a new teammate joins, this is what tells them what data already exists.
Reviewing it every quarter catches the two things that quietly break targeting: properties nobody sends any more, and near-duplicate events created by someone who didn't know the original existed.
If you're not sure what to put down
Email support@appcues.com with your Appcues Account ID and a description of what you're trying to launch. Send it before your developer starts, not after.