Localized news and sports using Amazon Location Service

As mobile experiences evolve, Amazon Web Services (AWS) continues to innovate by launching services that facilitate near-real-time, personalized, and interactive features for customers. Now broadcasters and publishers have a new solution to engage viewers and fans through compelling location-aware experiences that enrich mobile content.

With the launch of Amazon Location Service, location functionality can be easily added to applications to build near-real-time and location-driven mobile app features natively on AWS. Amazon Location Service provides secure and simple-to-integrate resources for geocoding, maps, geofencing, tracking, and routing.

This blog post provides three reference architectures: two approaches for integrating Amazon Location Service into content localization and one for geolocalized live streaming. The localization reference architectures described in this post benefit from using the least precision necessary to respect consumer privacy about viewer locations while optimizing performance. The caching mechanism to achieve this through decimal precision is explained. 

Mobile content localization

Today, news and weather mobile apps use content localization to provide relevant data to viewers about their surroundings. Viewers streaming live video from a broadcaster’s mobile app can be presented with a personalized schedule of available channels customized to their location, subscription package, and preferences.

When you’re defining a well-architected localization solution, it’s important to decide the level of precision required for your scenario to optimize costs and enhance the viewer experience.

To localize mobile content and app features, mobile solutions reverse geocode a viewer’s latitude and longitude to determine their location. Geocoding is more accurate than internet protocol (IP) address lookups because IP geolocation is generally to the city level. For mobile, cell tower location configuration and carrier decisions for handling cellular data affect the IP addresses assigned by cellular carriers.

The Places feature of Amazon Location Service performs a reverse geocode operation, converting latitude and longitude coordinates into a street address using data provided by Esri and HERE Technologies. The Places function for this conversion is SearchPlaceIndexForPosition.

Reference architecture: Geocoding service

But is a street address really necessary? When you’re considering user privacy, lookup latency, and query redundancy, it’s important to define the appropriate level of precision required to deliver your mobile content or experience. In a stadium, that could be a seating area. For a large broadcast radio or television market that spans multiple towns and cities, precision might be more broad to aggregate viewers across a large area. Places on Amazon Location Service lets you select the optimal combination of privacy and practicality by defining the precision you need.

Latitude and longitude precision

Latitude and longitude coordinates convey precision in degrees, presented as decimals, with each decimal place representing a different measure of distance (when measured at the equator).

A three-digit decimal place provides an accuracy of 111 m (364 ft.), and a two-digit precision provides an accuracy of 1.1 km (0.68 mi.).

Diagram: Latitude and longitude decimal precision to aggregate viewers by distance

Open-source schemes for aggregating and anonymizing data, like geohashing, can produce a single identifier for coordinates, which is more cache friendly for lookups than truncated coordinate precision is.

Consider a sports broadcasting company with specific location restrictions on where it can show content. The required level of precision might be the media’s designated market area covering a city, state, or region. The mobile app location service should consider the following:

1. How precise a location is required
2. How frequently viewers change location

In this example, the sports broadcaster can use one decimal of precision to determine and aggregate all viewers in a city. Because a viewer generally watches from the same location in the city where they reside, it is possible to minimize costs and optimize performance when you’re geocoding their location.

To limit redundant requests from viewers in a similar location (the city) or a static location (their homes), you can use the Places feature to cache previous lookups locally in your Amazon Web Services (AWS) account. You can specify this option when creating a Places index resource by configuring IntendedUse=Storage in the AWS API or console. You can check the cache before sending a new request to the geocoding service.

If one or multiple mobile viewers return latitude and longitude coordinates that are similar up to one decimal place (11.1 km or 7 mi.) to a result already cached locally, and that is precise enough for the use case, then additional lookups to Amazon Location Service are not required. This reduces cost and latency.

Reference architecture 1: Headless CMS content localization

When a mobile solution uses a headless content management system (CMS), Amazon Location Service can be implemented into one of the microservices in the following diagram.

Reference architecture: headless CMS content localization service

AWS AppSync—a fully managed service that makes it easy to develop GraphQL APIs—provides a serverless GraphQL backend capable of querying multiple databases, microservices, and APIs from a single GraphQL endpoint. This lets mobile apps retrieve data in the format needed. The geocoding service reverse geocodes the viewer’s latitude and longitude coordinates either from cached data or by making a new Places request to Amazon Location Service. Once the viewer’s location is returned, the content localization service proceeds with retrieving and aggregating localized data from the content service, content recommendations from the personalization service, and applying any viewer preferences from the subscriber service.

Reference architecture 2: Dynamic routing to different content origins using Amazon CloudFront

Another approach for content localization is to use Amazon CloudFront, a fast content delivery network service. By using the Amazon CloudFront Global Edge Network—which provides reliable, low-latency, and high-throughput network connectivity—you can build localization into Lambda@Edge, a feature of Amazon CloudFront that lets you run code closer to users of your application. This improves performance and reduces latency. Here, a mobile viewer’s geographical location is determined before dynamic routing to request content from different origins.

AWS edge localization capabilities

Previously, localization using Amazon CloudFront was limited to estimating the viewer’s location based on IP address during origin requests. Using Amazon Location Service, you can improve the precision of Amazon CloudFront routing through a Lambda@Edge function.

Consider a scenario where you need to augment Amazon CloudFront using location data rather than internet data points like IP addresses or data speed. You have a media CMS using Amazon CloudFront and want to augment data in or out with geolocation signals.

Reference architecture: Content localization at the AWS edge

Amazon CloudFront and Lambda@Edge natively support localization by IP address using data provider MaxMind. By using Amazon CloudFront alongside MaxMind, you can perform localization at the country level for all viewer requests and by IP address–determined city, postal code, latitude, and longitude when you’re making origin requests. Now your mobile application improves accuracy by sending mobile GPS geolocation data in the request body to Amazon CloudFront, a process in which a Lambda@Edge function uses Amazon Location Service to convert to a precise city, state, or postal code. 

Live streaming localization

Broadcasters can use Amazon Location Service in their mobile solution to provide viewers with a localized selection of available channels and programs and to determine the appropriate live stream for that viewer.

For live broadcast, a playback API providing the live stream manifest URL to an over-the-top mobile device can use an entitlement microservice to do the following:

• Determine the local TV station when a viewer is streaming a national channel
• Determine if a viewer can stream a live sports game based on their geolocation

You can build this entitlement logic natively on AWS, using Amazon Location Service to look up the broadcaster’s local station and streaming entitlement rules for the channel or current program.

Live streaming entitlement logic for local stations and live sports broadcast rules

A playback service determines the correct live stream manifest URL for the viewer’s location, device, and requested channel.

In this architecture, a live stream might be available from either Amazon Interactive Video Service (Amazon IVS), which is a managed live streaming solution, or AWS Elemental MediaLive, a broadcast-grade live video processing service. Amazon IVS offers a low-latency HTTP Live Streaming experience with audience interactivity through timed metadata insertion. By using AWS Elemental MediaLive alongside AWS Elemental MediaPackage—which helps you reliably prepare and protect your video for delivery over the internet—you can support more video devices that require Dynamic Adaptive Streaming over HTTP (DASH), Common Media Application Format (CMAF), and Microsoft Smooth Streaming video formats or live streams that require digital rights management encryption. The playback service selects the live streaming option based on parameters sent in the viewer’s request.

Reference architecture: Geolocalized live streaming

The playback service is implemented as a serverless representational state transfer (REST) API using Amazon API Gateway and AWS Lambda. Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale, and AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes. A REST API maintains simplicity where few request and response parameters are used and where the response payload of a playback URL is consistent across all devices. Here, the playback service accepts the channel, latitude, and longitude and returns a playback URL if the viewer is entitled to the live stream.

The reuse of the geocoding service in this architecture minimizes the latency and optimizes the performance of the playback service. Because the mobile app uses the geocoding service for content localization as the viewer navigates content, the viewer’s coordinates are stored and cached.

Security and consumer privacy

Amazon Location Service can only receive location coordinates if the viewer agrees to share their location from their device and from the app or website they are viewing from.

Consumer mobile device operating systems provide privacy features for end users that can highlight, restrict, or limit how their location data is provided to apps.

To respect consumer privacy, use the least precision required for your use case and requirements. The localization use cases described in this blog post all benefit from less precision for mobile solution operators because broader device coverage optimizes performance for a greater cache hit on stored Places index results.

When location data sends from a consumer mobile device to AWS, the security of Amazon Location Service benefits from the AWS shared responsibility model. Amazon Location Service extends this with its own security best practices for Amazon Location Service and mechanisms for data privacy when requests are made to data providers for geocoding.

For Places requests, Amazon Location Service anonymizes all queries sent externally to data providers by removing customer metadata, app metadata, and account information. Geofencing and tracking features do not use data providers or require local caching implementations because all data remains in your AWS account.

When you’re sending latitude and longitude coordinates from mobile devices, there are best practices for protecting data in transit:

• When you’re sending viewer coordinates from a mobile device over the public internet, latitude and longitude should be sent in the POST body of the request to your HTTPS service endpoint on AWS. Data Protection in AWS AppSync and Security in Amazon API Gateway support HTTPS endpoints with Transport Layer Security 1.2 only.
• Sign requests using Signature Version 4. It is recommended to use AWS software development kits or AWS Amplify—a set of tools and services to help build scalable full-stack applications—because they perform request signing when sending API requests.
• Activate AWS monitoring and logging tools, as seen in the documentation for security best practices for Amazon Location Service, AWS Lambda monitoring and observability, and logging and monitoring in Amazon API Gateway.

Pricing

Amazon Location Service features described in this blog post use the Places feature.

The localization architecture examples featured in this blog post incur Places request-based usage for Positions that are reverse geocoded with stored results; Places index results cache locally to optimize performance of future requests from viewers at a similar location. In the US East Region, requests that store Places geocoded data are charged at $4.00 per 1,000 requests. Requests that do not store Places geocoded data are charged at $0.50 per 1,000 requests. You can explore Amazon Location Service and experiment with it using the AWS Free Tier, which lets you gain free, hands-on experience using AWS.

For more information, refer to Amazon Location Service Pricing.

Getting started

Amazon Location Service is now available in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), Europe (Ireland), Europe (Stockholm), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo) Regions.

See demonstrations of all Amazon Location Service features using the visual explorer tool in the AWS Management Console, which has everything you need to access and manage AWS in one web interface.

Find out how to get started on Amazon Location Service.