pixelconversions

Pixel Conversions Service

In light of iOS 14.5, death to 3rd party cookies, Privacy awareness and so on, we need another way to let Users track conversions that are supported by major players

https://www.notion.so/Facebook-Pixel-Conversion-Service-f607f1bb2fa649bcac3d408daa1ce6c3?n=activity_block_edited&n=slack

Tech Overview

EventBridge has all out analytics events passing through it, for our Pixel feature we care about PageViewed and LinkClicked

This service will listen to those events that have the pixel attributes set in the payload, and then if the token is set we send an event via Facebooks Conversion API.

This can be scaled out to other providers, but for the moments it's just Fb.

Notable connections:

1. Lambda to save to dynamo
2. Redis in front of dynamo for retrieval (token will rarely change)
3. Lambda invoked directly from symfony to return a boolean if the token is set
4. Lambda that listens to View/Click events on profiles, to then further send API calls to Fb Conversions API

Users flow

1. A user inputs their pixel in admin
2. Then then user will input their pixel token
3. The token directly invokes a lambda to save the token and other attributes in dynamodb
4. When a user returns, or refreshes the admin page, we will only show a boolean if its set. The user can overwrite, but not review the already set pixel token
5. When events start coming in from profiles, a lambda will invoke. If all the required data is present, we will then hit the Fb Conversions API on their behalf with their token, the event name and the necessary payload

TODO / Scalability

• other providers (TikTok, GA)
• support our internal Linktree pixel (not just our users one)
• send event to perform actions and notify a user when a pixel token is invalidated or no longer works, requesting action
• not require direct lambda sync invocation

Wishlist:

• fetch/refresh the token on a users behalf (if ever supported)

Getting Started

With Docker installed, first build all images included with the service by running yarn build:all. This will build and cache the image for these services locally so they can be used when needed. Note: for now, these images must be rebuilt manually to pick up any changes to the service's packages using the command above.

Local Development

Dependencies:

• yarn
• docker compose
• ltd

Also seek access to the Linktree Facebook Business Manager account, ID: 232270757921431. Within this account, select one of the existing Linktree Developer Pixels and generate a new Access Token by following the instructions here.

Getting started

1. Run ltd service:develop
2. Ensure the lambdas which you wish to test are selected, then press the enter key.
3. Run yarn invoke:upsertPixelAccessToken [stringified json input] where [stringified json input] includes a valid Linktree account ID, a valid Facebook Pixel ID stored with that Linktree account ID, and a valid Facebook Pixel Access Token for the provided Facebook Pixel ID.
4. Run yarn dynamodb-admin to start the DynamoDB admin, then view it at http://localhost:8001/. Validate that your Pixel's Access Token has been saved.
5. Run yarn invoke:profileViewed [stringified json input] where [stringified json input] is a valid EventBridge ProfileViewed event referencing the Linktree Account ID and Facebook Pixel Token passed in step 3.

Local Deployment

Dependencies

• yarn
• docker compose

Instructions

1. Whenever a change is made to any file, run docker compose -f docker-compose.ci.yml build cdk from the root of the service
2. Run aws-vault exec legacy -- yarn stacks:[environment] where [environment] is substituted for the environment you're looking to deploy to, to list the stacks that can be deployed
   • Note: when running yarn stacks:qa, the production stacks will also be listed. It is important not to interact with these when the environment passed in the command does not match.
3. Select one of the stacks from the output of step 2 that matches the environment you passed in step 2. Run aws-vault exec legacy -- yarn diff:[environment] [stack name] where [environment] is substituted for the environment you're looking to deploy to, and stack name is an output from step 2 that should be deployed to that environment. This will show the changes that will be made to the environment on the next deploy of this stack.
4. Select one of the stacks from the output of step 2 that matches the environment you passed in step 2. Run aws-vault exec legacy -- yarn deploy:[environment] [stack name] where [environment] is substituted for the environment you're looking to deploy to, and stack name is an output from step 2 that should be deployed to that environment.