Optimizing AdTech end-user experiences Using Amazon CloudWatch Internet Monitor

In this blog post, we will explain how you can leverage Amazon CloudWatch Internet Monitor to monitor internet conditions continuously to ensure optimal ad workflow and delivery. In the realm of digital programmatic advertising (AdTech), various platforms such as supply-side platforms, ad exchanges, demand-side platforms, data & customer management platforms, and others collaborate to assist publishers in discovering creative methods of generating revenue from their content. These platforms provide opportunities for advertisers to connect with their desired audience by offering ad spaces.

AdTech companies move to AWS to take advantage of the breadth and depth of AWS services, and to benefit from the highly scalable, low latency network infrastructure. However, they can be impacted by the latency and availability of internet paths which reside outside of the AWS network. To help ensure their customers’ ad experiences load quickly and seamlessly, AdTech companies should monitor the performance and reliability of all routes and networks involved in the path between applications, publishing platforms, supply-side platforms, and demand-side platforms. This includes routes across various cloud providers, on-premises setups, or co-location facilities so that companies can fine-tune their network routing.

Amazon CloudWatch Internet Monitor allows you to maintain ongoing and uninterrupted visibility of internet conditions. It enables you to address any performance issues promptly, specifically those that result in latency degradation in network paths, ensuring optimal ad workflow and delivery. By utilizing this tool, you can ensure uninterrupted monitoring of your ad platforms network. You can harness information obtained from Internet Monitor to optimize programmatic bidding and enhance your ad delivery processes.

Architecture of AdTech workloads

Figure 1 illustrates the life cycle of an ad and the approximate latency requirements for each player in the AdTech ecosystem.

Figure 1: Diagram showing an ad life cycle

• • When a user accesses a webpage or a mobile app with ad spaces, an ad request is sent to an ad exchange or supply side platform.
  • The ad exchange initiates an auction and sends a bid request with a time-to-live (TTL) to bidders on the Demand-side platform (DSP). The DSP evaluates the bid request and promptly responds with either a bid or a no-bid response within the specified time to live (TTL).
  • After receiving multiple bids, the ad Exchange chooses the highest bid and sends an ad response containing a URL to the ad creative. The browser or app then fetches the ad creative from the provided URL and displays it on the user’s screen.

  The interacting systems that work with an ad Exchange platform might be geographically remote and technologically separate from each other. For example, one system might be hosted at an on-premises data center, while another might be located with a separate cloud provider, outside of AWS.

  Finding the best ad price in the fewest milliseconds and delivering an ad to the publishing platform without user-perceived delays are the key goals of an ad Exchange platform. To achieve these goals, two properties of network paths are especially important.

  • Latency: ad Exchanges require a high degree of responsiveness to ensure that Ads are delivered in real-time.
  • Reliability: ad Exchanges require highly reliable and available networks. Downtime and disruption can result in lost revenue and negatively impact an ad Exchange’s reputation.

  When the ad Exchange ecosystem includes interconnected entities that are geographically separated, the success of a workflow relies on the stability and performance of the internet connectivity between them. For example, the network paths that support ad bidding flows shown with dotted lines in Figure 1, are critical for meeting ad Exchange goals, but these paths are subject to the impact of internet weather. Internet weather refers to fluctuations in traffic quality over the public internet, caused by unusual or unexpected latency spikes. Ensuring that you monitor for, and can quickly mitigate, these fluctuations in latency is critical for maintaining a good customer experience.

  Using Internet Monitor to optimize the ad experience

  To help ensure an excellent customer experience for publishers and their end consumers, an ad Exchange platform should run real-time bidding and ad delivery on optimal network paths. You can use Internet Monitor to help you understand the traffic paths over the internet that ad Exchange workflows take, and to determine if the availability and performance of the paths has an impact on your traffic. To learn how to set up Internet Monitor for the resources in your workloads, see the Getting started steps in the user guide.After you create a monitor for your workload’s resources, Internet Monitor creates health events when issues impact your application’s performance and availability, so that you can track down and address issues. You have several options for how to be alerted about health events that Internet Monitor creates. You can decide how and when to be alerted based on your requirements for filtering and historical records types, then take action when an alarm is triggered.

  CloudWatch Internet Monitor provides the following options to notify applications of any health events.

  • CloudWatch alarms based on the Internet Monitor events metrics for performance and availability scores
  • CloudWatch alarms based on a metric generated by using a metric filter in CloudWatch Logs
  • Amazon EventBridge rules that filter health events

  To see how each of these might help you provide a better customer experience, let’s apply them to scenarios that can impact an AdTech workload.

  Scenario 1: Loss of availability for a network path for an ISP in New York

  The following diagram (Figure 2) illustrates a simple example of an ad Exchange ecosystem indicating where the different components are hosted and focuses on two workflows:

  • The real time bidding workflow between the ad Exchange and DSPs.
  • The ad delivery workflow between the End user, Publisher ad Server and ad Exchange.

Figure 2: Customer Ad Exchange platform in United States

In the above example, The ad Exchange platform is hosted in us-east-1 AWS region and the Publisher ad server is located in a co-location facility in West Virginia. The ad Exchange receives the ad request from the publisher ad server and decides to send bid requests to two DSPs, one in New York and the other in New Jersey.

Based on the monitoring performed by CloudWatch Internet Monitor, the ad Tech customer sees a drop in the availability score for the network path from New York to the ad Exchange endpoint in the us-east-1 AWS Region. The drop in health score and the resulting health event are shown under Traffic health scores on the dashboard Overview tab along with a visual map indicating the location of the health event in figure 3.

Figure 3: Internet Monitor shows a drop in performance and availability scores on the ad Network path

The health events table on the same page, after the graph and map, provides more information about the location, estimated traffic impact and triangulation result. When you select an event, Internet Monitor shows detailed information about the event, including a hop-by-hop network path visualization, if available. The following screenshot (Figure 4) shows an example of selecting New York to see the health event details.

Figure 4: Health event table showing the availability issue in the network path between New York and us-east-1

The health events can be used to change the workflow of the ad Exchange, as shown in Figure 5.

Figure 5: Using Health Events from CloudWatch Internet Monitor for ad Tech Workflow

This health event triggers an EventBridge rule, as shown in Figure 5, and the health event information is sent with EventBridge and triggers a Lambda function and updates the ad Exchange platform application logic. The application evaluates the data and determines that the impacted traffic path will impact its workflow from DSP1 in New York. Based on this, the application updates its workflow, eliminate DSP1 from real time bidding. This will help the ad Exchange to save both processing and data transfer costs until the route to DSP1 stabilizes.

Scenario 2: Increased round-trip time for a network path in India

In this scenario, the ad Exchange platform is hosted in ap-southeast-1 AWS region to support the Asia Pacific market, as shown in Figure 6.

Figure 6: Customer ad Exchange platform in Asia Pacific

The publisher ad server is located in a data center in Malaysia. The ad Exchange receives the ad request from the publisher ad server and decides to send bid requests to two DSPs, one in Singapore and the other in Tokyo.

In the example illustrated in figure 6, users from India are accessing a website of a publisher hosted in Malaysia. The Publisher is using the ad Exchange to make requests to fill the ad inventory on their website.

During ongoing monitoring, Internet Monitor detects that although the network path from India to its endpoint is still available, its performance has degraded. The drop in the performance score, and the resulting health event, are shown under Traffic health scores on the dashboard Overview tab, in the screenshot in figure 7.

Figure 7: Internet Monitor dashboard shows performance degradation for network path from India

When there’s internet performance degradation for your application, the application might be sensitive to traffic round trip times. In addition to health events, Internet Monitor publishes measurements to Amazon CloudWatch Logs that include performance and availability scores, bytes transferred, and round-trip times (RTT), for the locations and network providers specific to your application clients. The following screenshot (Figure 8) shows example event files that Internet Monitor publishes to CloudWatch Logs.

Figure 8: Internet Monitor events published to CloudWatch Logs

Instead of just relying on health events, you can use more granular information on the round-trip time data that’s published to CloudWatch Logs. For example, to track and help ensure the performance level that you expect for round trip speed for your ad delivery, create a custom metric filter on your Internet Monitor event logs, internetHealth.performance.roundTripTime.p90. By tracking the p90 sensitivity of the metric, CloudWatch alerts on anomalies that would be missed if you use the average. You also avoid triggering the alerts too frequently.

In Figure 9, you can see an of example data from the Internet Monitor dashboard Historical explorer tab with a graph of round-trip time for the network path from India, showing that it has steadily increased.

Figure 9: Round-trip time for network path from India shows a steady increase

You can create a CloudWatch alarm based on the custom metric, internetHealth.performance.roundTripTime.p90, to change the path and improve performance for requesting ad bids. When the alarm triggers, you can configure it to send a message with Amazon SNS, to which the ad Exchange application has subscribed. This approach is shown in Figure 10.

Figure 10: Using CloudWatch Alarms based on Internet Monitor Metrics for ad Tech workflow

Whenever the round-trip time performance for the network path in India falls below the p90 threshold, it triggers the workflow, which then notifies the ad Exchange platform. The ad Exchange platform can then use that information to provide an alternate location for fetching the ads such as Amazon CloudFront location in order to ensure optimize ad delivery experience.

Summary

The reduced downtime and higher availability of the ad Exchange platform provides efficient and effective ad delivery, improving the experience for your customers. Internet Monitor can also help ensure that programmatic advertising is a process served over low latency, reliable paths, to optimize the experience for publishers and end users. Visit Advertising Technology on AWS page to learn how these workloads can be architected on AWS.