In a nutshell, aampe uses the characteristics and behavior of your users to continuously personalize messages, i.e. decide which user receives what message when. It then triggers those messages at the right time and monitors their influence on long-term user behavior.
For that to happen, aampe needs to be able to:
- Ingest user characteristics (attributes) and behavior (events/transactions)
- Trigger messages through a messaging service provider
Messaging service integration
This integration happens on our side. We make sure that we are able to call the API of the provider you instrumented your app/website with (Push notifications) or the messaging provider you use (WhatsApp/SMS/E-mail).
Once you’ve told us which provider you use, the following steps happen:
- We provide you with a list of precise questions to learn how you're using this provider. For example: the identifier used to target a user, the details of how your team implemented deep links (if applicable), etc.
- You securely share your API credentials with us.
- We implement any needed adaptations to our integration code.
- We test that messages are sent and delivered - for that you provide us with a couple of user IDs/phone numbers that we can target for testing (usually members of the team or test devices you use) or, in the case of push notifications, an APK that we can install locally so we do the testing ourselves.
Note: certain customers have custom-built solutions for messaging. In that case, your technical team can share the API specification they’ve implemented and we’ll be more than happy to integrate that into our system.
User data integration
We want the integration to be as light-weight as possible, this way time is saved and we are able to kick-off early. There are several ways to achieve that, depending on your preference and stack:
- If your app/website is already instrumented with an online service that tracks user events (e.g. MixPanel), aampe can pull the data directly from their API. If we are to implement this solution, the only thing we need from your side is the API credentials (and eventually some details about the events and attributes you collect there)
- For attributes and events shared straight from your data warehouse, the easiest solution is to set up a shared bucket (depending on your cloud provider). Your team can then dump data points to this bucket (JSON, ndJSON, CSV) and our system will ingest those directly from there. For this solution, if we take AWS as an example: you will create an S3 bucket, we will provide you with the ARN of an IAM user and a list of credentials for you to include in the bucket’s permissions. Your team will then start pushing data daily into this bucket which our system will ingest at a given time every day.
- Similar to option number 2, but instead of using storage buckets we can provide you with an SFTP server where you upload the daily data dumps).
At aampe, we call your users contacts because they are the entities we connect to and communicate with. To be able to communicate with those contacts, we need the set of events and attributes specified This is the minimum requirement, and you are encouraged to add as much useful information as you wish we take into consideration when segmenting your contacts.
- timestamp - Event timestamp
- timezone - Timestamp timezone
- event_name - Name of event
- contact_id - Internal ID used identify unique users
- metadata - A collection of data points relevant to the event
Note: certain customers opt for carving-out only a subset of their users for pilot purposes. We do not recommend this. If this situation is inevitable, please make sure that when adding new users to this pool of carved-out users, you keep pushing event data for the previously carved-out users.