Audience Activations with Sendlane

introduction this document provides an overview of how to use our sendlane sync using chord's audiences api sendlane is a marketing automation platform that unifies email, sms, forms, and reviews to boost retention, personalization, and revenue the primary focus when it comes to audience activations with sendlane via chord is to add customer tags defined through chord’s pre built and custom audience dashboards this enables email segmentation and personalization by delivering dynamic audience data as contact tags to sendlane if you get stuck or have additional questions as you review this documentation, feel free to reach out to us at mailto\ help\@chord co — our team is also happy to help you activate audiences on other cms tools or platforms that help you get your job done! chord to sendlane activation flow chord platform application audiences are created via the chord platform per the existing flow integration with dynamodb chord extracts audience data from our snowflake warehouses and stores it in an aws dynamodb table aws lambda function an aws lambda function receives the updates and forwards them as contact tags to sendlane sendlane the synchronized contact tags can now be utilized in building targeted segments and lists using the auidence tag on the contact integration details chord requires the sendlane v2 api key to setup the sync it only supports audiences with email as the primary key and audience as the secondary key when syncing audiences from snowflake to dynamodb (setup is shown in the sections below) customers emails need to exist in sendlane to have a tag added this does not add new customers to sendlane dynamodb destination chord will handle the connection to the dynamodb destination for you you can view it as part of your https //docs chord co/data activations creating a sync using our sync ui, we first need to create a new sync that connects a custom audience as the source and our dynamodb table as the destination as a chord tenant, you will have access to your own dedicated dynamodb table the example below is using chord audiences for documentation purposes select sync behavior sync behaviors dictate the types of change that should be applied to your data when a sync finds a matching (or not) record in a source and a destination available sync behaviors are update or create (aka upsert) update existing destination records when ids match, otherwise, create new records if they're missing mirror keep the destination in sync with the source if a row is added or edited in the source, update the destination if a previously synced row no longer is in the source, remove the matching object from the destination mirror syncs identify changes by comparing against the data they have already sent not the data that might or might not already exist in the destination this means that the first sync will be an upsert for all records, and the second and following syncs will account for changes from the source data sync key note the following steps (sync key, field mapping) are more advanced and should be handled by chord employees or individuals with a strong understanding of the feature sync keys will dictate how to associate data in the source with the destination both the source and destination need to provide a single, unique per record, identifying field the identifiers will be used to look for matches when a match is found or not found we then can use your selected sync behavior to decide what to do your sync key can be any kind of unique identifier, like a user id, an email address, etc however, we do recommend using a “blended user id” provided by chord if possible (see below) mapping with a blended user identifier some audiences may contain what we call a “blended user id,” which is derived from the chord data models to contain the cdp user id if one exists else the anonymous id this use case is particularly useful when mixing users that may or may not have a known cdp user id this means that you will be able to look up a user via the audience api using either a cdp anonymous id or a known user id (in this case) when using blended id, it is very important to keep in mind that if you query an anonymous id that was identified at any point, our api won't return any result field mapping once you've defined how data is related between your source and destination, the next step is to determine what properties should be updated the field mapping step lets you specify how fields should be mapped from your source model to the destination object's fields we start by assigning our unique user identifier anonymous current cdp blended user id will become our pk (primary key) we can then set up the sk (sort key) it is important to ensure that this value reflects the name of the audience being synced you can easily obtain that value by choosing sync metadata > source name you should end up with the following sync schedule like any https //docs chord co/gfnf data activations on the chord data platform, the sendlane sync can be scheduled to run at regular intervals the chord platform will display the sync results on the data activations page when you click into the "manage syncs" button