How AWS’ Lambda@Edge Service Could Ease Web Content Personalization
With digital, data-driven, distributed-at-scale architecture comes the possibility of better personalizing website content and experiences for every single user. Can surfing the web look more like a personal conversation or customized business interaction from the start?
Amazon Web Services’ Lambda@Edge, launched into general availability in July, aims to integrate serverless edge processing with its content delivery network nodes so that applications can customize content for each single user who visits.
Lambda@Edge functions provide read/write access to request parameters such as a URL, cookies and headers as well as allowing access to remote resources on origin facing events. Together, these services allow website and application developers to build custom responses that match each individual’s needs.
Lambda@Edge locations functions are triggered by requests to the Amazon CloudFront content delivery network service, a global network of 79 edge locations and 11 regional edge caches across 22 countries. Lambda@Edge users do not pay additional costs to transfer data to Amazon CloudFront, and are able to make calls to a range of other AWS services on origin facing functions.
Challenges of CDN-Based Personalization
Increasingly, websites are making calculated guesses about who is visiting them in order to provide more personalized, contextual content immediately. Services like Clearbit’s Reveal API allow developers to use a website or application visitor’s IP address to identify key attributes that might then help to customize the content immediately. If such an API was deployed alongside the Lambda@Edge infrastructure, where function code can be triggered close to the visitor’s location, dynamic content could be served in ways that might enhance visitor engagement.
A good example of the sort of early contextual signals that determine content being delivered is Stripe’s API documentation. A visitor arriving at the developer portal home page would see a list of what payments are available in their currency and country. Immediately, developers can see if the Stripe integration is suitable to their use case.
Being able to deliver that kind of customized content may be okay for Stripe’s global architecture, but any other business wanting to offer that kind of context, one way would be to run functions at CDN nodes in advance of user requests to be able to send the right web content to the user within a short enough timeframe that the arriving reader feels that it is seamless.
If developers are logged in to their account with Stripe, they see even more personalized content that might match where they are in the engagement and API consumption journey. Lambda@Edge could make that sort of customized experience available to any business that is providing an API and developer portal.
Imagine, for example, if a developer receives an error message when she tries to make an API call, so she opens the API documentation for that API. Using a scheme that identifies and parses cookies and headers, function code at the edge could make instant decisions around which documentation pages to serve via corresponding redirects, or create a personalized message referring the developer to the content that could help her with her error case.
The developer portal is just one use case: businesses could personalize information for return shoppers or service customers, or offer up relevant content to single page apps that maintain engagement across a range of verticals.
Lambda@Edge provides a range of tools to help this sort of personalized web content:
- Headers can be inspected and functions can be written to make decisions about delivering tailored content based on user location and device, these header responses can then be cached locally to further reduce latency when sending more content.
- HTTP responses can be generated on the fly from the AWS CloudFront location closest to the user, whether that be customized error pages, auto-generated login pages for unauthenticated users, or static pages.
- Dynamic URLs can be created to avoid exposing business decisions about how content is managed internally and instead served as pretty URLs that match directory structures that reflect how visitors have arrived at the web page.
- Authorization can occur at the edge by using functions that leverage cookies to control content access. Users can login the first time and then edge functions manage their access after that.
- Edge functions can be written to introduce A/B testing with a simpler splitting of real-time users into control groups without providing separate URLs.
In his blog post first describing the release, AWS Chief Evangelist Jeff Barr explained:
“Functions are globally replicated and requests are automatically routed to the optimal location for execution. You can write your code once and with no overt action on your part, have it be available at low latency to users all over the world. Your code has full access to requests and responses, including headers, cookies, the HTTP method (GET, HEAD, and so forth), and the URI. Subject to a few restrictions, it can modify existing headers and insert new ones.”
Already, AWS clients are using Lambda@Edge to speed up secure content delivery to customers. Portland-based cryptographic software company Tozny uses AWS S3 and CloudFront to store static scripts and HTML/CSS data. By using Lambda@Edge, they use security headers on all content delivered to their customers over CloudFront. A Lambda@Edge function adds headers for Content Security Policy, Strict Transport Security, and XSS protection so that user data is encrypted in a browser or mobile app, stored as encrypted data and then accessed as a JSON object when it is decrypted in the authenticated end user’s client. “Lambda@Edge helps us achieve both scale and security for our cutting edge browser-based cryptography product,” CEO, Isaac Potoczny-Jones, has stated in Amazon materials.
Of course, there is a danger in too much personalization. Already in social media news feeds, algorithms may keep sending you the news you want to hear from the perspective you want to hear rather than sharing a diverse range of views and perspectives on the world at large. Music discovery algorithms could narrow your listening tastes by constantly recommending the same genre of songs each week, ignoring new tastes and flavors that may appeal. A web personalized for each individual loses the excitement of discovery and deadens the environment in which curiosity and happy coincidence can bloom.
But in some specific areas — especially where a conversation between an individual and a business, such as between a developer and an API developer portal, or between a customer and their supplier/retailer — personalizing web content can speed up the usability in much the same way that end users now expect a CRM to connect to a support desk so that they don’t have to repeat their reason for contacting a chatbot or in-app service desk. Bringing edge functionality, CDNs, and contextual content together could create that in-app and chatbot messaging experience to any website a visitor lands on.
Feature image: Photo by Andreas Selter on Unsplash.
