How we brought in-app messages to our app | Part 1: Segment (CDP), a Lambda and a DynamoDB

The idea we started with for in-app messages was simple.

We needed to display public messages, like outages or force version updates (we have never had to actually use these) and we needed targeted messages for a service that our marketing team can control.

The public messages were simple enough but targeted messages needed more.

The idea

Segment, our chosen CDP (customer data platform), has a list of audiences created by our marketing team. These audiences or cohorts are defined when customers meet specific data attributes. A service or customer is either part of that audience or not.

So, we needed to query the CDP for a list of “audiences” that a customer has been allocated to then return a list of messages that correlate to those audiences to the app.

The idea

In practice

We added a very simple endpoint to the our API layer, a mono-repo of serverless apps, where we request traits from the CDP and filter down to active audiences, while also checking that a customer is opted in to messages.

At the same time we look up the the active messages stored in DynamoDB then filter based on the audiences, ie. A message has a list of audiences that the message can be shown too, we only show a message that has overlap with a customers service audiences.

For Public messages, like outages etc. we just bypass the "CDP look up" and show the message to anyone opening the app so long as the message is marked as active and public.

in practice, the flow

How it looks

Here is how an in app message looks, we recently did a competition to win a phone with a high amount of messages served to our customers in a single day.

How it looks in the app and perfomance, 120ms average

The api is also super fast. We validate customer login, look the customer up in the CDP, get and filter the relevant messages from DynamoDB, all in around 120ms.

The final piece

Finally, the last part of the build, was an "authoring tool" to set up a message. This uses Flutter web for the UI to leverage the design system we already have in our Flutter based app to make it look as close to the real thing as possible, Serverless and deploys to an S3 via a CI pipeline.

This gives our Marketing team a simple self-serve UI to build and preview a message and our customers get fast, personalized in-app messaging.

In part 2 we will show how we improved on this further with SFMC and journey builder.

The views expressed on this blog post are mine alone and do not necessarily reflect the views of my employer, Optus Administration Pty Ltd

Previous
Previous

Unit testing with Android

Next
Next

Tips on Creating Unit Tests Using Jest