Audience Activations with Ninetailed

introduction this document provides an overview of how to use our ninetailed sync using chord's audiences api ninetailed is a personalization and experimentation platform built for modern, headless cms and e commerce setups it enables marketers and developers to deliver tailored content and experiences to different user segments the primary focus when it comes to audience activations with ninetailed via chord is to add profile traits defined through chord’s pre built and custom audience dashboards this enables real time personalization by delivering dynamic audience data to ninetailed 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 ninetailed 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 dynamodb stream a stream of events generated form changes to the table are queued aws lambda function an aws lambda function receives the events via a connected stream trigger to process and bulk send up to 50 “identify” events per request if emails are used as the primary key for an audience, the emails are hashed before being sent as the id to ninetailed conentful/ninetailed the synchronized traits can now be utilized in building targeted content using the trait attributes on the profile sample request to ninetailed chord requires the following two items to setup the sync to the https //www contentful com/developers/docs/personalization/experience api/#batch upsert profiles api key environment curl location 'https //experience ninetailed co/v2/organizations/{api key}/environments/{env}/events' \\ \ header 'content type application/json' \\ \ data '{ "events" \[ { "channel" "server", "context" { "library" { "name" "chord audiences", "version" "1 0 0" } }, "messageid" "58f358f2 a858 11ed afa1 0242ac120002", "anonymousid" "(userid || anonymousid)", "userid" "(userid || anonymousid)", "traits" {"audience firsttimebuyer" "true" }, "type" "identify" }, { "channel" "server", "context" { "library" { "name" "chord audiences", "version" "1 0 0" } }, "messageid" "58f358f2 a858 11ed afa1 0242ac120002", "anonymousid" "(userid || anonymousid)", "userid" "(userid || anonymousid)", "traits" {"audience superfan" "false" }, "type" "identify" } ] }' if emails are used as the primary key for an audience, the emails are hashed before being sent as the id if you would like to fetch the profile through ninetailed using the email, you can obtain the id through this code snippet async function hashemail(email) { 	const encoder = new textencoder(); 	const data = encoder encode(email tolowercase()); 	const hashbuffer = await crypto subtle digest('sha 256', data); 	const hasharray = array from(new uint8array(hashbuffer)); 	const base64hash = btoa(string fromcharcode( hasharray)); 	return base64hash replace(/\[^a za z0 9]/g, '') substring(0, 32); } 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 ninetailed 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