Delivering personalised content at scale with Smart Links - Part 2

In part 1, we covered the challenges in personalizing visuals at scale and how teams can use Smart Links to solve these challenges. Let us switch gears and dive into the technical details of Smart Links. We will cover:-

1. Search Algorithm

2. System Design

Search Algorithm

Problem Statement: Find the k most relevant variants from the n variants in a project

Input: n creative URLs, each with a set of m key-value pairs of metadata

Expected Output: k most relevant creative URLs

Algorithm

We built a modified version of K-nearest neighbors to solve the search problem. Based on the input key-value pairs, we generate a score between 0-k for every variant inside the project. We then sorting the variants in descending order of the generated score and pick the first k variants.

Time Complexity: O(n * m)

Example

Let us start with the 4 variants we looked at in part 1.

1. age group: 30-45, gender: male, location: London, purchases: 5+

2. age group: 20-30, gender: male, location: Delhi, purchases: 2-5

3. age group: 20-30, gender: female, location: San Francisco, purchases: 5+

4. age group: <20, gender: male, location: Sydney, purchases: 0-2

Let us say we are searching for a creative with gender: male and purchases: 0-2. We start with a base score of 0 for all the variants. We match the given key value pairs with each variant’s metadata. Each match is 1 point.

1. Variant 1: Gets 1 point as it matches gender: male

2. Variant 2: Gets 1 point as it matches gender: male

3. Variant 3: Gets 0 point as it does not match anything

4. Variant 4: Gets 2 points as it matches gender: male and purchases: 0-2

When we sort by the score, variant 4 comes out on top with a score of 2.

JS implementation

System Design

There are 2 parts to this architecture:-

1. Rendering - Creatives are rendered using a combination of Lambda (serverless) and auto-scaling EC2. They are stored in S3 with the URL saved in a MongoDB database.

2. Delivery - The API uses CloudFront, load balancer, Lambda, and Redis.

Architecture of Smart Links

CloudFront

1. Is integrated with Lambda using Load Balancer as there is no direct way to connect Lambda and CloudFront

2. Is used to cache JSON response and/or binary creative data

3. JSON responses are cached against query parameters (for sending search attributes) and headers (for authentication)

4. Checks for same request in the nearest edge location, reducing overall latency drastically

5. Changes made to project in Rocketium triggers an invalidation request in CloudFront distribution so users always have the latest content

Load balancer

1. Just acts as a middleware to connect Lambda and CloudFront

2. Mapped as an origin inside respective CloudFront distribution

3. A behaviour needs to be defined for endpoint /api/v1/creatives to redirect request to mapped load balancer

Lambda

1. Avoids having to manage dedicated servers and scaling

2. Uses search algorithm defined above to find the most relevant creatives

3. Uses reserved concurrency to save cold start time and improve latency

Redis

1. Data retrieval is much faster from Redis than a database

2. In case of miss, variant metadata is fetched from MongoDB and cached in Redis

3. Lambda checks for a hit in Redis first before making a database call

Conclusion

In these two parts, we learned about the why, how, and what of Smart Links. Coming soon is Cortex, a layer on Smart Link which harnesses its power to run personalised in-app campaigns. Until then, see it in action at https://rocketium.com/is/in-app-campaigns/.