Traffic reports

Cloud Interconnects Traffic report

The Cloud Interconnects report allows you to estimate how much of your cloud origin egress traffic is successfully sent through Private Network Interconnects (PNIs).

The Cloud Interconnects behavior maximizes traffic flow through PNIs provided by some cloud hosting providers.

The KPI sections shows estimated Total Traffic, Traffic over PNIs, and percentage of Traffic using PNIs. The report presents bytes only.

📘

The report dates are in GMT. Your cloud service usage report may show dates in local time, so take this into account if comparing ​Akamai​ reported origin traffic against your cloud provider’s reporting.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Groups (optional). Groups let you narrow down your content to groups of CP codes.

Metrics

KPI metrics

  • Origin. Estimated bytes served from cloud origins for time period.

  • Interconnects. Estimated cloud origin bytes served through PNIs for time period.

  • Interconnects vs. Origin. Estimated PNI egress traffic as opposed to cloud origin egress traffic.

Interconnect usage (chart) metrics

  • Origin traffic. Estimated bytes of traffic from cloud origins for date range.

  • PNI traffic. Estimated bytes of traffic egressing through PNIs for date range.

Interconnect traffic by CP code (table) metrics

  • CP code. Content provider code.

  • Origin bytes. Estimated bytes of traffic from cloud origin for this CP code over this time frame.

  • PNI bytes. Estimated bytes of traffic egressing through PNIs for this CP code over this time frame.

  • PNI bytes %. Estimated PNI bytes / cloud origin bytes for this CP code and time frame.

📘

Traffic in portions of Southeast Asia may not accurately reflect PNI usage, even though those connections are utilized.

Traffic report

The Traffic report provides hits, volume, bandwidth, and offload data over time for your web delivery products.

This means edge traffic (traffic from the edge servers to end users), midgress traffic (traffic between the servers), and origin traffic (traffic from your origin). You can choose to show the base metrics for the page in hits or bytes. Some filters and metrics depend on your selection.

Depending on whether the cacheability filter is enabled or not, the offload graph is yellow (for cacheable) or purple (for non cacheable) data. There is no offload for non cacheable content.

📘

The metrics show average traffic data (not peak).

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Groups (optional). Groups let you narrow down your content to groups of CP codes.

  • Cacheability. Distinguishes cacheable content from non cacheable content. Selecting a non-cacheable filter lets you see non-cacheable traffic even if offload is zero, offload for content that is redirected responses served from the edge, and offload for content generated at the edge.

  • Delivery type (optional). Distinguishes secure traffic from non-secure traffic.

  • IP (optional). Supported array values are IPv4 and IPv6. If no IP version is selected, the report shows data for both IPv4 and IPv6.

  • Response status (optional). An indicator showing success or failed HTTP response.

  • Response class (optional). A class of HTTP response status codes, from 0XX through 6XX.

  • Response code (optional). An HTTP response status code, for example, 404.

  • Traffic (optional). HTTP traffic to be included in the report data.

    • All Responses - Includes all response traffic.
    • PUT/POST Responses - Response traffic from PUT and POST operations.
    • GET/HEAD Responses - Response header traffic from GET operations.
    • PUT/POST Requests - Request traffic from PUT and POST operations.
  • HTTP Method. A request method indicating the action performed on a resource.

Metrics

  • Bytes offload. The volume of traffic served by ​Akamai​ that did not require hits on your origin.

  • Average bytes offload. The average volume that was served from cache as a percentage of total volume served.

  • Maximum bytes offload. The peak volume that was served from cache as a percentage of total volume served.

  • Minimum bytes offload. The lowest volume that was served from cache as a percentage of total volume served.

  • Edge bits per second. The edge bandwidth for given objects and filters.

  • Maximum edge bits per second. The peak edge bandwidth for given objects and filters.

  • Minimum edge bits per second. The lowest edge bandwidth for given objects and filters.

  • Total edge bytes. The total volume of edge traffic for given objects and filters.

  • Edge hits per second. The number of edge requests per second for given objects and filters.

  • Maximum edge hits per second. The peak number of edge requests per second for given objects and filters.

  • Minimum edge hits per second. The lowest number of edge requests per second for given objects and filters.

  • Total edge hits. The total number of edge requests for given objects and filters.

  • Hits offload. The number of hits that served as a percentage of total hits for given objects and filters.

  • Average hits offload. The average number of hits that served as a percentage of total hits served for given objects and filters.

  • Maximum hits offload. The peak number of hits that served as a percentage of total hits served for given objects and filters.

  • Minimum hits offload. The lowest number of hits that served as a percentage of total hits served for given objects and filters.

  • Midgress bits per second. The bandwidth between servers for given objects and filters.

  • Maximum midgress bits per second. The peak bandwidth measurement between servers for given objects and filters.

  • Minimum midgress bits per second. The lowest bandwidth measurement between servers for given objects and filters.

  • Maximum origin bits per second. The peak origin bandwidth for given objects and filters.

  • Total midgress bytes. Volume delivered between servers for given objects and filters.

  • Midgress hits per second. The number of requests between servers per second for given objects and filters.

  • Maximum midgress hits per second. The peak number of requests between servers per second for given objects and filters.

  • Minimum midgress hits per second. The lowest number of requests between servers per second.

  • Total midgress hits. All hits with all response codes delivered between servers.

  • Origin bits per second. The origin bandwidth for given objects and filters.

  • Minimum origin bits per second. The lowest origin bandwidth.

  • Total origin bytes. The total volume of origin traffic for given objects and filters.

  • Origin hits per second. The number of origin requests per second for given objects and filters.

  • Maximum origin hits per second. The peak number of origin requests per second for given objects and filters.

  • Minimum origin hits per second. The lowest number of origin requests per second for given objects and filters.

  • Total origin hits. The total number of origin requests for given objects and filters.

  • Edge hits per second by response class. The rate of edge requests per second by HTTP response class for given objects and filters, for example, 2xx.

  • Origin hits per second by response class. The rate of origin requests per second by HTTP response class for given objects and filters, for example, 2xx.

  • Edge hits by response class. The number of edge requests by HTTP response class for given objects and filters, for example, 2xx.

  • Edge hits percent by response class. The number of edge requests per second by HTTP response class, for example, 2xx, as a percent of all edge hits.

  • Origin hits by response class. The number of origin requests per second by HTTP response class for given objects and filters, for example, 2xx.

  • Origin hits percent by response class. The number of origin requests per second by HTTP response class for given objects and filters, for example, 2xx, as a percent of all edge hits.

  • Edge hits by response. Edge hits by response.

  • Edge hits percent by response. Edge hits percent by response.

  • Origin hits by response. Origin hits by response.

  • Origin hits percent by response. The number of origin requests per second by HTTP response for given objects and filters, such as 201, as a percent of all edge hits.

  • Maximum midgress hits. The peak number of requests between servers out of 5 minute data chunks for the given objects and filters.

  • Maximum origin hits. The peak number of origin requests out of 5 minute data chunks.

  • Maximum edge hits. The peak number of edge requests out of 5 minute data chunks.

  • Maximum midgress bytes. The maximum volume delivered between servers out of 5 minute data chunks.

  • Maximum edge bytes. The maximum volume of edge traffic out of 5 minute data chunks.

  • Maximum origin bytes. The maximum volume of origin traffic out of 5 minute data chunks.

  • Edge hits by HTTP version. The request count delivered from Akamai edge servers to the end user by request method.

  • Edge hits percentage by HTTP version. The portion of all requests delivered from Akamai edge services to the end user by request method.

  • Edge bytes by HTTP version. The volume for the traffic delivered from Akamai to the end user by request method.

  • Edge bytes percentage by HTTP version. Edge bytes percent by request method

📘

Be aware that changes to your Property configuration, such as cache settings may in turn change the shape of data subsequently reported.

Today's Traffic report

Today's Traffic Report provides hits, volume, bandwidth, and offload data for the most recent 48 hours for your Web delivery products.

Edge traffic (traffic from the edge servers to end users), midgress traffic (traffic between the servers), and origin traffic (traffic from your origin) are called out. You can choose whether you want the base metric for the page to be hits or bytes.

📘

The metrics show average traffic data (not peak).

Data granularity
The default granularity for this report, which shows data for the last 48 hours, in five-minute intervals.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Groups (optional). Groups let you narrow down your content to groups of CP codes.

  • Response class (optional). A class of HTTP response status codes (0XX, 1XX, 2XX, 3XX, 4XX, 5XX, 6XX ).

  • Response status (optional). An indicator of whether the HTTP response was successful or failed.

Metrics

  • Bytes offload. The volume of traffic served by ​Akamai​ that did not require hits on your origin.

  • Average bytes offload. The average volume that was served from cache as a percentage of total volume served.

  • Maximum bytes offload. The peak volume that was served from cache as a percentage of total volume served.

  • Minimum bytes offload. The lowest volume that was served from cache as a percentage of total volume served.

  • Edge bits per second. The edge bandwidth for given objects and filters.

  • Maximum edge bits per second. The peak edge bandwidth for given objects and filters.

  • Minimum edge bits per second. The lowest edge bandwidth for given objects and filters.

  • Total edge bytes. The total volume of edge traffic for given objects and filters.

  • Edge hits per second. The number of edge requests per second for given objects and filters.

  • Maximum edge hits per second. The peak number of edge requests per second for given objects and filters.

  • Minimum edge hits per second. The lowest number of edge requests per second for given objects and filters.

  • Total edge hits. The total number of edge requests for given objects and filters.

  • Hits offload. The number of hits that served as a percentage of total hits.

  • Average hits offload. The average number of hits that served as a percentage of total hits served for the given objects and filters.

  • Maximum hits offload. The peak number of hits that served as a percentage of total hits served for the given objects and filters.

  • Minimum hits offload. The lowest number of hits that served as a percentage of total hits served for the given objects and filters.

  • Midgress bits per second. The bandwidth between servers for given objects and filters.

  • Maximum midgress bits per second. The peak bandwidth measurement between servers for given objects and filters.

  • Minimum midgress bits per second. The lowest bandwidth measurement between servers for given objects and filters.

  • Maximum origin bits per second. The peak origin bandwidth for given objects and filters.

  • Total midgress bytes. Volume delivered between servers for the given objects and filters.

  • Midgress hits per second. The number of requests between servers per second for the given objects and filters.

  • Maximum midgress hits per second. The peak number of requests between servers per second for the given objects and filters.

  • Minimum midgress hits per second:. The lowest number of requests between servers per second for the given objects and filters.

  • Total midgress hits. All hits with all response codes delivered between servers.

  • Origin bits per second. The origin bandwidth for given objects and filters.

  • Minimum origin bits per second. The lowest origin bandwidth for given objects and filters.

  • Total origin bytes. The total volume of origin traffic for given objects and filters.

  • Origin hits per second. The number of origin requests per second for given objects and filters.

  • Maximum origin hits per second. The peak number of origin requests per second for given objects and filters.

  • Minimum origin hits per second. The lowest number of origin requests per second for given objects and filters.

  • Total origin hits. The total number of origin requests for given objects and filters.

📘

Be aware that you affect report data by configuring details such as cache settings, or by making changes to a configuration within the time period of the report you're viewing.

Traffic by Geography report

The Traffic by Geography report returns traffic data by country or area. This report shows only 200 OK hits.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Groups (optional). Groups let you narrow down your content to groups of CP codes.

  • Delivery type (optional). Distinguishes secure from non-secure traffic.

  • Country/area (optional). The country or area generating traffic.

  • HTTP Method. A request method indicating the action performed on a resource.

Metrics

  • Edge hits. The number of edge requests for given objects and filters.

-Edge bytes. The number of edge bytes for given objects and filters.

  • Country/area. The country or area generating traffic.

📘

Be aware that changes to your Property configuration, such as cache settings may in turn change the shape of data subsequently reported.

Traffic by Server Country report

The Traffic by Server Country report returns daily traffic data by server country or region.

API Acceleration traffic is identified by Small Payload Size (less than 5kB), single transactions and low cacheability. Any traffic that is served as a response for the API requests generated by the clients constitutes for this traffic.

This report gives you the Usage Traffic by Hits and Bytes for all API acceleration traffic from a designated Server Country (served from). The data you get is very close to billing metrics you can see in your invoice.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Groups (optional). Groups let you narrow down your content to groups of CP codes.

  • Delivery type (optional). Distinguishes secure from non-secure traffic.

  • Country/area (optional) . The country or area generating traffic.

Metrics

  • Total hits. The number of edge requests for given objects and filters.

  • Total bytes. The total number of bytes being served from the country or region.

Traffic by Browser and OS report

The Traffic by Browser and OS report provides information about what browser types and operating systems are generating traffic.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Groups (optional). Groups let you narrow down your content to groups of CP codes.

Metrics

  • Hits by browser. The number of edge requests by browser type.

  • Percent hits by browser. The percent of all edge requests for the identified browser.

  • Hits by OS. The number of edge requests by operating system.

  • Percent hits by OS. The percent of all edge requests for the given operating system.

📘

Be aware that changes to your Property configuration, such as cache settings may in turn change the shape of data subsequently reported.

Top Visitors report

For the top unique IP/user agent combinations, the following information is provided.

  • Domain/IP. The domain, if known, and the IP address from which the visitor is requesting your content.

  • Hits. The number of OK or successful hits on your content this visitor is producing. This number includes hits on the edge server from the end user with successful response codes only (such as 2xx, 3xx, 0xx).

  • Volume. The amount of bandwidth this visitor is using to request your content. This number includes hits on the edge server from the end user with successful response codes only (such as 2xx, 3xx, 0xx).

Page Views report

The Page Views report returns page view (text/HTML) file data over time. The page views count doesn't include pages with response codes 301, 302, and 404. It does include pages with 403 and 400 response codes.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Groups (optional). Groups let you narrow down your content to groups of CP codes.

Metrics

  • Page views. The total number of page views.

  • Minimum page views per second. The lowest rate of page file delivery per second.

  • Maximum page views per second. The highest rate of page file delivery per second.

📘

Be aware that changes to your Property configuration, such as cache settings may in turn change the shape of data subsequently reported.

Unique Visitors report

The Unique Visitors report returns unique visitor data over time. Unique visitors are determined by unique combinations of end user IP addresses plus user agent.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • IP (optional). Supported array values are IPv4 and IPv6. If no IP version is selected, the report shows data for both IPv4 and IPv6.

Metrics

  • Unique visitors. The number of unique combinations of client IP addresses plus user agent.

  • Average unique visitors. The average number of unique combinations of client IP addresses plus user agent for the selected date range.

📘

Be aware that changes to your Property configuration, such as cache settings may in turn change the shape of data subsequently reported.

Daily Unique Visitors report

The Daily Unique Visitors report returns daily data for unique combinations of IP address and user agent. When querying multiple days worth of data, you receive the maximum (MAX) daily value across the entire date range for each of the dimensions.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Groups (optional). Groups let you narrow down your content to groups of CP codes.

Metrics

📘

When querying multiple days worth of data, you receive the maximum daily value across the entire date range.

  • Average unique visitors. The average number of unique combinations of client IP addresses plus user agent for the selected date range.

  • Minimum unique visitors. The lowest number of unique combinations of client IP addresses plus user agent for the selected date range.

  • Maximum unique visitors. The highest number of unique combinations of client IP addresses plus user agent for the selected date range.

  • Unique visitors by country/area. The number of unique combinations of client IP addresses plus user agent by country or area.

  • Unique visitors by state. The number of unique combinations of client IP addresses plus user agent by U.S. state.

  • Unique visitors by province. The number of unique combinations of client IP addresses plus user agent by Canadian province.

  • Unique visitors by browser. The number of unique combinations of client IP addresses plus user agent by browser.

  • Percent unique visitors by browser. The percent of all unique combinations of client IP addresses plus user agent for this browser.

  • Unique visitors by OS. The number of unique combinations of client IP addresses plus user agent by operating system.

  • Percent unique visitors by OS. The percent of all unique combinations of client IP addresses plus user agent for this operating system.

URL Traffic report

The URL Traffic report delivers traffic data by URL. You can choose to view this report by hits or bytes.

Key performance indicator (KPI) results are different for URL Traffic and Traffic report. The KPIs are based on all URL data.

HTTP URL data is stored only for URLs with at least 50 hits per day. This means that URLs with less than 50 hits per day are excluded from single day reports and reports that span multiple days will under-report the traffic for some URLs. The 50 hit requirement is in place to prevent customers with a large number of distinct URLs with few hits from overwhelming the reporting systems. This requirement has an impact on data returned by report. This explains why you may observe differences between URL responses and URL traffic reports.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Groups (optional). Groups let you narrow down your content to groups of CP codes.

  • Responses. You can select Error or Success.

  • Delivery type (optional). Distinguishes secure from non-secure traffic.

  • URL string. The portion of a URL with report data you want to see. You can put limits on the search with a custom string search (using the following match criteria: Contains, Starts with, Ends with, Does not contain, Does not start with, Does not end with, Match a regular expression, Does not match a regular expression, or Is an exact match ). You can also add a URL pattern to match, such as a file type extension or part of a directory name.

Metrics

  • Average hits offload. The average number of hits that served from cache as a percentage of total hits served, for given objects and filters.

  • Maximum hits offload. The peak number of hits that served from cache as a percentage of total hits, for given objects and filters.

  • Minimum hits offload. The lowest number of hits that served from cache as a percentage of total hits, for given objects and filters.

  • Total edge hits. The total number of edge requests, for given objects and filters.

  • Maximum edge hits per second. The peak number of edge requests per second, for given objects and filters.

  • Minimum edge hits per second. The lowest number of edge requests per second, for given objects and filters.

  • Total origin hits. The total number of origin requests, for given objects and filters.

  • Maximum origin hits per second. The peak number of origin requests per second, for given objects and filters.

  • Minimum origin hits per second. The lowest number of origin requests per second, for given objects and filters.

  • Edge hits. The number of requests delivered by ​Akamai​ for the associated URL.

  • Origin hits. The number of requests delivered by the origin for the associated URL.

  • Offload. The average number of hits delivered by ​Akamai​ for this URL as a percentage of total hits, for given objects and filters.

  • Average bytes offload. The average volume that was served as a percentage of total volume served.

  • Maximum bytes offload. The peak volume that was served as a percentage of total volume served.

  • Minimum bytes offload. The lowest volume that was served as a percentage of total volume served.

  • Total edge bytes. The total volume of edge traffic, for given objects and filters.

  • Maximum edge bits per second. The highest rate of edge requests per second, for given objects and filters.

  • Minimum edge bits per second. The lowest rate of edge requests per second, for given objects and filters.

  • Total origin bytes. The total volume of origin traffic, for given objects and filters.

  • Maximum origin bits per second. The highest rate of origin requests per second, for given objects and filters.

  • Minimum origin bits per second. The lowest rate of origin requests per second, for given objects and filters.

Top URLs edge hits / top URLs edge bytes
Provides traffic data for the top 5000 URLs with the highest number of edge hits or edge bytes associated with given objects and filters.

  • Edge. The total volume of edge traffic for this URL.

  • Origin. The total volume of origin traffic for this URL.

  • Offload. The total volume of traffic delivered by ​Akamai​ as a percentage of total volume served. For a specific URL.

  • URL. The URL of the specific content.

URL Responses report

The URL Responses report delivers HTTP response data by URL.

HTTP URL data is stored only for URLs with at least 50 hits per day. This means that URLs with less than 50 hits per day are excluded from single day reports and reports that span multiple days will under-report the traffic for some URLs. The 50 hit requirement is in place to prevent customers with a large number of distinct URLs with few hits from overwhelming the reporting systems. This requirement has an impact on data returned by report. This explains why you may observe differences between URL responses and URL traffic reports.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Groups (optional). Groups let you narrow down your content to groups of CP codes.

  • Responses. You can select Error or Success.

  • Delivery type (optional). Distinguishes secure from non-secure traffic.

  • URL string. The portion of a URL with report data you want to see. You can put limits on the search with a custom string search (using the following match criteria: Contains, Starts with, Ends with, Does not contain, Does not start with, Does not end with, Match a regular expression, Does not match a regular expression, or Is an exact match ). You can also add a URL pattern to match, such as a file type extension or part of a directory name.

Metrics (for given objects and filters)

  • Total edge hits. The total number of edge requests.

  • Maximum edge hits per second. The peak number of edge requests per second.

  • Minimum edge hits per second. The lowest number of edge requests per second.

Top URLs edge hits by responses
Provides traffic data for the top 5000 URLs with the highest number of responses associated with given objects and filters.

  • 0XX. The number of HTTP responses in the 0XX range for this URL.

  • 2XX. The number of HTTP responses in the 2XX range for this URL.

  • 3XX. The number of HTTP responses in the 3XX range for this URL.

  • 4XX. The number of HTTP responses in the 4XX range for this URL.

Origin Performance report

The Origin Performance report shows performance characteristics observed by ​Akamai​ edge servers when making requests to your origin servers. Metrics are collected as a request travels from the edge servers to your origin, and the associated response travels from your origin to the edge servers. The request/response represents an exchange between the edge servers and your origin.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Cacheability.
    Cacheable. Can be stored after an initial request for faster future delivery.
    Non-cacheable. Can't be stored (identified as "no-store" or have a 0 TTL) and always trigger an origin request.

  • Response Codes. HTTP response codes from your origin to edge servers.

Metrics

  • Origin response. The number of responses from your origin to edge servers.

  • Maximum origin responses. The highest number of responses from your origin to edge servers for the selected date range.

  • Origin response times. The elapsed time in milliseconds for request/response exchanges from ​Akamai​ edge servers to your origin.

  • Maximum origin response times. The highest elapsed time in milliseconds for request/response exchanges from ​Akamai​ edge servers to your origin.

  • Average origin response times. The average elapsed time in milliseconds for request/response exchanges from ​Akamai​ edge servers to your origin for the selected date range.

📘

Important factors that contribute to exchange time include geography between edge servers and origin, network conditions, and performance of your origin. Also, be aware of your caching settings.

SureRoute Performance report

SureRoute tests multiple routes between the edge server and the origin. These tests identify an optimal path for performance and establish alternative routes in cases of potential request failures.

The identified optimal path is used to improve performance with non-cacheable content. When SureRoute is enabled, edge servers request the same test object from the origin via three different routes, using the results of these occasional "races" to determine an optimal route to the origin.

The SureRoute Performance report shows the percentage of traffic traveling SureRoute's faster route. This report is based on the logs retrieved from the ​Akamai​ edge servers.

Route optimization data requires having a SureRoute test object available on your origin. If your report is not showing any data, make sure you've completed this configuration step.
If your SureRoute configuration uses custom maps, some origin hostnames may not show. In this case contact your representative to check that all origin hostnames are on your custom SureRoute map.

Keep in mind that the races to fetch the test object result in a small increase in origin traffic.

📘

SureRoute is automatically turned off for cacheable content. For the best performance you should serve it from an edge server cache and not over an origin route.

Data retention and granularity
The SureRoute Performance report is a real-time report that shows data for up to the last 10 days.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

Metrics (for the selected date range)

  • Route optimization, in percentage of optimized requests. The bandwidth reduction for your origin, expressed as the percentage of optimized requests or the percentage of requests where SureRoute provided a faster route. This is an aggregate view of traffic from the edge compared to traffic going to your origin.

  • Average route optimization. The average percentage of requests where SureRoute provided a faster route.

  • Minimum route optimization. The lowest percentage of requests where SureRoute provided a faster route.

  • Maximum route optimization. The highest percentage of requests where SureRoute provided a faster route.

Prefetching report

Prefetching instructs the ​Akamai​ edge server to retrieve embedded HTML content (objects), such as images and scripts, from the origin before the browser requests these objects. This can significantly decrease the load time and the display time of embedded objects.

The Prefetching report provides insight into the volume of responses served by the edge and your origin server when you are using the ​Akamai​ Instant (Page Prefetching) behavior in your ​Akamai​ configuration. Responses are based on time frame, traffic segments, and traffic type.

How you choose to set up ​Akamai​ Instant and other caching rules can affect the data in this report. Cacheability attributes of objects, in particular, have specific requirements for configuration.

Data granularity and retention
The Prefetching report shows data for the last 10 days. Date ranges up to two days show five-minute data, and ranges more than two days to 14 days show hourly data.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

  • Cacheability.
    Cacheable. Can be stored after an initial request for faster future delivery.

    • Must have Tiered Distribution enabled.
    • Must have a defined caching rule based on either filenames or URL extensions.
    • Must appear in the HTML tags: base, img, script, input, link, table, td, or th. Prefetching of cacheable content requires that you enable Tiered Distribution for that content.
      Non-cacheable. Can't be stored (identified as "no-store", or has a 0 TTL) and always triggers an origin request.
    • Must have SureRoute enabled.
    • The URL must end in either one of the following extensions.
    • The URL must be a request for a default file in a directory, as specified by ending in a "/". For example, "http://www.example.com/product/".
    • The URL appear in one of the following HTML tags: base, img, script, input, link, table, td, or th.

Metrics

  • Edge responses. The total number of all responses from the edge server to the end user.

  • Origin responses. The total number of all responses served from the origin.

  • Edge prefetch responses. The total number of edge cache hits for request messages correlated to no-store or low TTL objects. This value can be zero when it is related to no-store content.

  • Origin prefetch responses. The total number of responses served from the origin for prefetch requests, which includes embedded objects and ​Akamai​ Instant requests for prefetched pages.

  • Edge responses (per second). The rate of all responses from the edge server to the end user, in responses per second.

  • Maximum edge responses (per second). The highest rate of all responses from the edge server to the end user, in responses per second, for the selected date range.

  • Latest edge responses (per second). The most recent measurement of the rate of all responses from the edge server to the end user, in responses per second, for the selected date range.

  • Origin responses (per second). The rate of all responses served from the origin.

  • Maximum origin responses (per second). The highest rate of all responses served from the origin, for the selected date range.

  • Latest origin responses (per second). The most recent measurement of the rate of all responses served from the origin, for the selected date range.

  • Origin prefetch responses (per second). The rate of responses served from the origin for prefetch requests, which includes embedded objects and ​Akamai​ Instant requests for prefetched pages, for the selected date range.

  • Maximum origin prefetch responses (per second). The highest rate of responses served from the origin for prefetch requests, which includes embedded objects and ​Akamai​ Instant requests for prefetched pages, for the selected date range.

  • Latest origin prefetch responses (per second). The most recent measurement of the rate of responses served from the origin for prefetch requests, which includes embedded objects and ​Akamai​ Instant requests for prefetched pages, for the selected date range.

  • Edge prefetch responses (per second). The rate of edge cache hits for request messages correlated to no-store or low TTL objects. This value can be zero when it is related to no-store content.

  • Maximum edge prefetch responses (per second). The highest rate of edge cache hits for request messages correlated to no-store or low TTL objects for the selected date range. Note that this value can be zero when it is related to no-store content.

  • Latest edge prefetch responses (per second). The most recent measurement of the rate of edge cache hits for request messages correlated to no-store or low TTL objects for the selected date range. This value can be zero when it is related to no-store content.

Proxy Protection report

This report shows how ​​Akamai​​'s Enhanced Proxy Detection (EPD) service applies proxy detection and location spoofing protection when delivering your content.
EPD uses services provided by our data provider, GeoComply to identify requests for your content that have been redirected from an unwanted source through proxy. You can then allow, deny, or redirect these requests.

Fixed categories of proxy detection

​Akamai​​ leverages GeoComply's GeoGuard product for proxy detection. GeoGuard offers multiple categories to identify various types of unwanted proxy that may be used in a request. A list of these categories is kept on GeoComply's website.

When setting up EPD in your property configuration, you can select one of two Configuration Modes:

  • Best Practices. This is the mode ​​Akamai​​ recommends. It automatically uses all of GeoGuard's primary ("must-have") categories and you set a single action to apply for all of them — "Set it, and forget it."
  • Advanced. This lets you pick and choose from the "must-have" and "optional" categories and you can customize individual actions for each.

Remember how you've set your Configuration Mode when reviewing report data here. It impacts how data is revealed—whether it is, or isn't displayed in some cases.

Use the Proxy Protection report

  1. From the Reports menu or Reporting overview page, select the Proxy Protection report.
  2. Select filters:
    1. Date range (required). Click the date picker icon to adjust the date and time.
    2. Groups and Properties. Narrow down your content to groups of CP codes.
    3. CP codes (required). Select CP codes.
    4. IP Version. Select the applicable IP version for traffic — IPV4 or IPV6.
    5. HTTP version. Select the applicable version, either HTTP, HTTPS/1.1, HTTP/2, or HTTP/3
  3. Click Apply.
    The report loads with the following widgets:
    • KPI summary: Edge proxy hits (total), Applied matches (total), Actions taken (total).
    • Edge proxy hits, applied matches, and actions taken
    • Edge proxy hits, applied matches, and actions taken by CP code
    • Match category trend
    • Match category by CP code
    • Actions taken trend
    • Actions taken by CP code
      For descriptions, see Widgets table.
  4. To see results for a higher number of hostnames, access the widget data through API calls:
    1. Click the API calls icon next to the widget.
    2. Copy the API call into your API tool and run.
      For general information on how the reporting API works, see Reporting API.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.
  • Groups and Properties (optional). Groups let you narrow down your content to groups of CP codes.
  • Delivery type (optional). Distinguishes secure traffic from non-secure traffic.
  • IP (optional). Supported array values are IPv4 and IPv6. If no IP version is selected, the report shows data for both IPv4 and IPv6.
  • HTTP version (optional): Either HTTP, HTTPS/1.1, HTTP/2, or HTTP/3.

Widgets

Widget

Description

KPI summary

This widget shows overall EPD matches for requests from identified proxies and the number of actions taken. There are a few data points in this widget:
Edge Proxy Hits. This is the total number of hits to ​​Akamai​​ edge servers that came through a proxy.

Applied Matches. This is the total number of hits to ​​Akamai​​ edge servers from proxies that fall into GeoGuard's categories of proxy detection.

Actions Taken. You can select one of three actions to take when a request comes from a GeoGuard category of proxy detection: Allow, Deny, or Redirect. This shows the combined total for all actions taken after a proxy was detected.

Edge proxy hits, applied matches, and actions taken

This widget shows EPD matches for requests from identified proxies and the number of actions taken.

Edge proxy hits, applied matches, and actions taken by CP code

This widget shows EPD matches for requests from identified proxies and the number of actions taken, per individual content provider code (CP code).

Match category trend

This shows the frequency of requests from each of the various GeoGuard categories of proxy detection, over the specified range of time. It applies to all requests, across all CP codes.
Note: While the widget shows all GeoGuard categories in its key, the data shown depends on what you've selected for your EPD Configuration Mode. See Fixed categories of proxy detection section.

Match category by CP code

This widget shows all of the GeoGuard categories of proxy detection ("Applied Matches") for a specific CP code, in relation to the full total of Edge Proxy Hits for that CP Code.

Actions taken trend

This shows the frequency of allow, deny, and redirect actions taken, over the specified range of time. It applies to all requests, across all CP codes.
Note: While the widget shows all action types in its key, the data shown depends on how you've configured your actions for the EPD Configuration Mode you've selected. See Fixed categories of proxy detection section.

Actions taken by CP code

This widget shows totals for each deny ("Blocked Hits"), redirect ("Redirect Hits"), or allow ("Akamai Override") action taken for a specific CP code, in relation to the full total of Edge Proxy Hits for that CP Code.

Metrics

actionsTaken - Actions Taken
actionsTakenTotal - Total Actions Taken
akamaiOverride - Akamai Override Hits
akamaiOverrideTotal - Total Akamai Override
appliedMatches - Applied Matches
appliedMatchesTotal - Total Applied Matches
blockedHits - Blocked Hits
blockedHitsTotal - Total Blocked Hits
edgeProxyHits - Edge Proxy Hits
edgeProxyHitsTotal - Total Edge Proxy Hits
actionsTakenPercent - Actions Taken %
appliedMatchesPercent - Applied Matches %
hostingProviderHits - Hosting Provider Hits
hostingProviderHitsTotal - Total Hosting Provider Hits
proxyHits - Proxy Hits
proxyHitsTotal - Total Proxy Hits
redirectHits - Redirect Hits
redirectHitsTotal - Total Redirect Hits
smartDNSHits - Smart DNS Hits
smartDNSHitsTotal - Total Smart DNS Hits
torExitHits - Tor Exit Hits
torExitHitsTotal - Total Tor Exit Hits
vpnDataCenterHits - VPN Datacenter Hits
vpnDataCenterHitsTotal - Total VPN Datacenter Hits
vpnHits - VPN Hits
vpnHitsTotal - Total VPN Hits

Carbon Calculator report

The Carbon Calculator report provides detailed calculations around the amount of emissions your ​Akamai​ traffic generates while giving insight into ​Akamai​ platform emissions efficiency.

  • a summary across all countries of emissions and edge bytes for the selected time range and filters,
  • a time series across all countries of emissions and edge bytes for the selected time range and filters,
  • total bytes and emissions by country for the selected time range and filters.
    The granularity is one day, standard 3-month retention. Data is available from 15th of March 2022.

Use the Carbon Calculator report

  1. From the Reports menu or Reporting overview page, select the Traffic - Carbon Calculator report.
  2. Select filters:
    1. Date range (required). Click the date picker icon to adjust the date and time.
    2. Groups and Properties. Narrow down your content to groups of CP codes.
    3. CP codes (required). Select CP codes.
    4. Delivery type. Optionally select secure or non-secure traffic.
    5. Country/area. Optionally select the country or area generating traffic.
  3. Click Apply.
    The report loads with the following widgets:
    - the summary KPI section showing total edge bytes and total calculated emissions,
    - Calculated emissions and edge bytes in time,
    - Calculated emissions and edbe bytes by geography with a geo heatmap,
    You can switch between Edge bytes and Calculated emissions tabs to see specific data.
    - Calculated emissions and edge bytes by geography table.
  4. To see more results, access the widget data through API calls:
    1. Click the API calls icon next to the widget.
    2. Copy the API call into your API tool and run.
      For general information on how the reporting API works, see Reporting API.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

  • Time and date picker. The date and time range selected for a report helps to limit data and focus on what you want.
  • Groups (optional). Groups let you narrow down your content to groups of CP codes.
  • Properties (optional). Properties let you narrow down your content to given property CP codes.
  • CP codes. Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.
  • Delivery type (optional). Distinguishes secure traffic from non-secure traffic.
  • Country/area. The country or area serving traffic (served from).

Metrics

  • Edge bytes. The total edge traffic volume.This includes request and response bytes as well as overhead bytes for all request types (GET-HEAD, PUT-POST)

  • Calculated emissions. CO2 calculated emissions. The t unit stands for metric tonnes.

General emissions calculation disclaimer
The methodology used to calculate the carbon emissions information is believed to be accurate. However, no responsibility for either the accuracy of the information or the precision of the methodology will be assumed, and no liability for any decisions made or actions taken in reliance on the report will be accepted.

Edge emissions methodology summary
​Akamai​ has developed a methodology to attribute Greenhouse Gas Emissions (CO2e) to units of platform capacity measured against gigabytes (GB). This methodology was applied to every edge region across the ​Akamai​ Global Intelligent Platform and rolled up by country to give a detailed analysis of emissions output based on actual customer utilization. This method can calculate emissions output per GB of traffic accounted for on the platform. This granularity provides our customers visibility into their total CO2e emissions impact using ​Akamai​ Edge services globally. The emissions calculation is in line with the following globally accepted standards:

  • World Resources Institute (WRI)/World Business Council for Sustainable Development (WBCSD) Greenhouse Gas (GHG) Protocol Corporate Accounting and Reporting Standard (Scope 2).
  • WRI/WBCSD Greenhouse Gas Protocol Corporate Value Chain (Scope 3) Accounting and Reporting Standard (Scope 3).

Carbon emissions calculator general assumptions

  • A 3rd party verifier has not audited data displayed in each customer's carbon calculator. Data is assumed to be accurate based on the data sources from our network, renewable energy production, and our clean data center partners. All reports are subject to change at any time.
  • Baseline emissions factor data includes all ​Akamai​ Global Intelligent Edge network operations. The factors include hardware operations and related facility power usage effectiveness (PUE) adhering to greenhouse gas protocol Scopes 2 and 3.
  • PUE is calculated using our annual colocation survey, and results are averaged across our facilities to ensure proper emissions impact is appropriately allocated.
  • Data for our operations globally are broken down by network region and rolled up by country to create a unique emissions factor for each individual country.
  • Our emissions reductions are translated for our customers to view the overall impact. These reductions include attributions from our renewable energy projects, data center partners, and other emissions reduction sources based on our market-based emissions for Scope 2 and extended network Scope 3 in each country.
  • All emissions measurements are shown in Carbon Emissions Equivalency (CO2e)
  • ​Akamai​ platform emissions factors are calculated against the most current and validated sources, including:
    • US-eGRID
    • Location Marginal Emissions (LME) - When applicable, US Only
    • International Energy Agency (IEA)
    • Australia Government Industry
    • EU AIB European Residual Mix
    • Canada ECCC National Inventory Report
    • UK DEFRA GHG Conversion Factors
  • ​Akamai​ yearly emissions statement follows the ISO 14064-3 Second Edition 2019-04: Greenhouse gasses -- Part 3: Specification with guidance for the verification and validation of greenhouse gas
  • Network utilization totals are pulled directly from our distributed data collected (DDC) by customer to calculate Edge traffic emissions. The traffic totals are calculated by country to provide an overall emission impact by country.

Did this page help you?