Consolidate push and in-app messaging workspaces

How it works

Imagine you have two workspaces, one for each of your mobile apps, but the two audiences overlap. Rather than maintaining profiles with similar attributes and messages with similar content across two workspaces, you might want to manage everything from a single workspace.

To do this, you’ll pick the workspace you want to consolidate around, copy your messages from the old workspace into it, and release mobile app builds that point at the new, consolidated workspace.

As users update your app to the latest version, they’ll appear in your consolidated workspace and you can start to prune them from the old workspaces. When enough of your audience has updated your app and arrived in the consolidated workspace, you’ll retire the old workspaces. Then you’ll have a single workspace for all your profiles and mobile app messaging.

It’s important that as each profile arrives in the new workspace, you stop the old workspace from sending to them, so you don’t send them duplicate messages over channels that aren’t unique to a workspace—SMS, email, etc.

Why you can’t copy your audience over

Each build of your app talks to one Customer.io workspace. When you’re ready to consolidate your workspaces, you also need to update your app to point at the new workspace.

If you were to copy your audience over first, any users who hadn’t updated their app yet wouldn’t receive messages from the new workspace.

Instead, by updating your app first, you can identify users as they update. When they arrive in the workspace you consolidate around, you’ll know that they’re eligible for messages from the new workspace.

This applies to both push and in-app messages. Until someone updates:

• Their device fetches in-app messages from the old workspace, so it’s the only workspace that can show them in-app messages.
• Their device registered its push token with the old workspace, so that’s the workspace that sends them push notifications.

Consolidate your workspaces

Before you start, decide which workspace you want to consolidate around. That’s the workspace you’ll point your app builds at. Pick the one with the most engaged audience, and keep the app that’s already there as its default app.

Retiring the old workspace

It’s up to you to decide when to retire your old profiles or workspace. You may not want to delete profiles immediately, even if you flag them with an automation to ensure that they’re in the new workspace.

Before you delete profiles or the workspace, you want to make sure that profiles in the old workspace:

1. Have arrived in the new workspace.
2. Are no longer sending data/activity to the old workspace. If you still have active integrations or touchpoints pointed at the old workspace, users could still be interacting with them and sending data to the old workspace.
3. No longer receive messages from the old workspace. If you still have active automations that are valid for these users, you might not want to stop their journeys just yet.

You can either remove profiles individually, as you’re confident that they meet the criteria above, or remove the entire workspace when you’re confident that a significant amount of your audience meets the criteria above.

If you remove profiles individually, make sure that you don’t have active integrations or touchpoints that users can still interact with. If you do, you could inadvertently re-identify people in the old workspace after you delete them—which can affect billing and make it difficult to determine when you’re ready to retire the workspace.

Cross workspace automation

As users arrive in the consolidated workspace, you probably want to flag them in the old workspace. This gives you criteria you can use to filter them out of automations or messages, and helps you determine when you’re ready to retire profiles from the old workspace.

To affect users in your old workspace, you’ll set up a webhook.

1. Get your old workspace’s Track API credentials.

2. In the consolidated workspace, create an automation and set the trigger to use an attribute that indicates that someone has arrived in the new workspace. You might use an attribute in your new workspace that you set when you identify them, like consolidated: true.

3. Add a webhook action to the automation workflow.

4. In the webhook action:

   1. Set the HTTP method to PUT.

   2. Set the URL to https://SITE_ID:TRACK_API_KEY@track.customer.io/api/v1/customers/{{customer.email}}, replacing SITE_ID and TRACK_API_KEY with the credentials from step 1. The webhook action doesn’t have separate authentication fields; you add basic authentication credentials to the URL. Replace {{customer.email}} with customer.id if you use a shared ID to identify users in both workspaces.

      Note

      If your old workspace is in the EU region, use track-eu.customer.io instead of track.customer.io.

   3. Use the request body to set the attribute you want to flag the user with, and also set _update to true. This ensures that you don’t inadvertently create a profile in the old workspace if the identifier doesn’t match anyone there:

      {
      "consolidated": true,
      "_update": true
      }

   Send a test request

   Try sending a test request to the old workspace’s Track API to make sure it works. For the test, you might want to unset _update to create a profile in the old workspace if the identifier doesn’t match anyone there. That’ll help you prove the webhook end-to-end.

5. Save the webhook and start the automation.

Now, as people arrive in the consolidated workspace, the automation will flag them in the old workspace, and you can stop sending them messages.