The new API docs can be found here: https://apidocs.mediamath.com/docs/reporting-api-v2
<!-- theme: warning -->
Notice about adama_cookie
Support for adama_cookie will be removed later this year. We ask all of our clients who have not yet migrated to OAuth2 authorization to do so as soon as possible.
The Reports API on MediaMath Platform allows advertisers to access, query and aggregate reporting data. It is also the API that powers all reporting seen on our MediaMath Platform flagship UI.
The Reports API offers a number of reports. Each report offers its own pre-aggregated, time-based metrics on entities that users can query. A query can filter, aggregate, sort, paginate, and format this data.
It is a read-only system meaning no request against it can alter the data in any way.
It is also a metadata-driven system. The supported reports are described in a human- and machine-readable format. This ensures easy one-off and repeatable programmatic data querying. It also provides a way for clients to adapt to changes in reports programmatically. This gives client-developers the ability to create UIs that provide useful operational feedback in a navigable and understandable way.
The $API_BASE for the latest version of Reports API is
Report data is stored and output in a tabular format. This means that the output consists of rows and columns. Every row has a value for every column.
The structure object can be used to determine the columns a report can output. Its fields are divided among three mappings - time_field, dimensions, and metrics. Each mapping, maps field name to #model:Fqbi8siNTuFGqA2W5.
The time field represents the time-component of the report's metrics. There is (currently) only one time field for each report. It can be of one of these data types: datetime or interval. Its data type determines the type of report (datetime or interval based report).
Note: The type of report is not to be confused with the Type attribute. The Type attribute is purely informational.
The time field was distinguished from the dimension fields to allow its use in grouping and filtering rows easier to understand. It gets its own set of parameters and language.
datetime-typed Time Fields
Datetime-typed time fields contains a combination of year, month, day, and possibly down to hour, minute and second. The time_aggregation property indicates the field's finest grain (by_hour, by_day, etc). The time_rollups property indicates the available grouping options that can go beyond the time_aggregation of the report.
time_rollup=by_week ### group rows by the week - week starts on Monday time_rollup=by_month ### group rows by the monthtime_rollup=all ### produces at most one row of output per combination of dimension fields ### listed in the dimensions parameter
The time field for these reports are typically represented in the output by a start_date and end_date column. The format of the column will depend on the time window and time_rollup.
YYYY-MM-DD
YYYY-MM-DD hh:mi:ss
The only exception to this rule is detailed in the Special Time Windows section.
The timezone of the start_date and end_date columns will match the timezone property.
interval-typed Time Fields
interval-typed time fields, contain a predefined non-calendar date based aggregation (1 day, 7 days, 30 days, and so on). In this case, the only accepted way to specify a time interval is by using the parameter time_window. The only value supported for the parameter time_rollup for interval-based reports is all.
The time field for these reports are represented in the output by a interval column. The value of the column will depend on the time_window chosen. The following gives example column values based on the time_window.
yesterday - 1
last_7_days - 7
last_30_days - 30
campaign_to_date - CTD
flight_to_date - FTD
Filtering with the Time Field
The API requires the specification of a time window in order to narrow the data set operated on. A time window must be specified in one of the two possible ways.
start_date and end_date (optional - defaults to "yesterday").
time_window may be set to one of the formats defined by the time_windows attribute.
### operate on data timestamped between Jan 01, 2013 and Feb 01, 2013, inclusivestart_date=2013-01-01&end_date=2013-02-01 ### operate on data timestamped between May 05, 2013 and yesterday, inclusivestart_date=2013-05-01 ### other usage examples time_window=last_30_days time_window=month_to_date time_window=yesterday
start_date and end_date
start_date and end_date may only be used when the report's time field is of the datetime type. They may not be used when the report's time field is of the interval data type. This is because the time_windows are pre-defined intervals that cannot be split.
The start_date and end_date parameters define inclusive boundaries for the data. In order to ease the burden of calculating an inclusive end, the inputs may be specified at various granularities.
month - YYYY-MM
day - YYYY-MM-DD
hour - YYYY-MM-DDThh
minute - YYYY-MM-DDThh:mi
second - YYYY-MM-DDThh:mi:ss
Each granularity matches a substring of the ISO 8601 format.
If the report is at a coarser granularity (see time_aggregation) than the input, the input will be taken to mean the entirety of the time unit.
start_date=2016-04-12T01%3A30%3A00&end_date=2016-04-12T02%3A30%3A00# ie. start_date=2016-04-12T01:30:00&end_date=2016-04-12T02:30:00# For a report with a time_aggregation of by_hour:# 2016-04-12T01:00:00 to 2016-04-12T02:59:59.# For a report with a time_aggregation of by_day:# 2016-04-12T00:00:00 to 2016-04-12T23:59:59
time_window
All values mentioned in the time_windows array will be accepted verbatim by the time_window parameter with the exception of any time window that starts with last_X_. They may be interpreted as such.
The last_X_days time window ends yesterday (inclusive) and starts X days before that.
The last_X_hours time window ends at the previous hour (inclusive) and starts X hours before that.
Future windows of this type may be defined following this nomenclature, but for different units. Rules for the time window may vary slightly.
Special Time Windows
The following time_windows are considered to be special time windows.
campaign_to_date
flight_to_date
For reports with a datetime-typed time_field, the start_date and end_date columns that would normally be present, will be replaced by the interval column. Additionally, the following validation rules apply when a special time_window is chosen.
The results will have an interval column instead of start_date and end_date columns.
The time_rollup parameter must be set to all.
Any mention of the time_field for the report in the order parameter will be rejected.
Dimension Fields
Dimension fields describe an entity. The example reports provide dimension fields for campaign, and strategy entities. Dimension fields are used to group rows during aggregation in conjunction with the time field.
Metric Fields
Once the rows have been grouped. The metric fields are calculated based on the values of the group's underlying rows. These calculations are generally sums or averages. These fields are usually a numeric data type.
Please note that fees (eg: managed_service_fee, optimization_fee, platform_access_fee, and mm_total_fee), cost (eg: adserving_cost, adverification_cost, media_cost, and tota_ad_cost), and margin data are only available to users who have “edit margin” access.
Data Types
The id type allows any character except whitespace.
The datetime type may be filtered by dates, or datetimes in either of the following ISO 8601 based formats.
date - YYYY-MM-DD
datetime - YYYY-MM-DDThh:mi:ss
Year, month, and day are all 1-based. Hour, minute, and second are all 0-based. Valid hours are 0-23.
The dimension fields of the datetime type will always be output in the aforementioned datetime format. The output columns for the time field will be output in the same format, but without the separating 'T'.
Field Data Type Groupings
This documentation may refer to multiple data types via a group name. The following table details the group names.
The new API docs can be found here: https://apidocs.mediamath.com/docs/reporting-api-v2
Parameters
Parameter names are case sensitive, (see the table below).
Most parameters will fall under one of the following two formats.
enumeration of comma-separated items (used in aggregation, selection and sorting);
example:
dimensions=campaign_id%2Ccampaign_name%2Ccampaign_start_date (in other words, campaign_id,campaign_name,campaign_start_date)
list of logically AND-ed expressions, joined by ampersand (used in dimension and metric filtering);
examples:
filter=campaign_id%3D12345%26strategy_id%3D98765 (in other words, campaign_id=12345&strategy_id=98765)
having=impressions%3E%3D500%26clicks%3C100 (in other words, impressions>=500&clicks<100)
Query Options
A query can filter, aggregate, sort, paginate, and format a report's data.
Filtering is required. It must be done on the time field, and one or more dimension fields that have their access property set to true. It can be done both before and after aggregation.
Aggregation, like filtering, is also required. The grouping must be performed against the time field and a combination of one or more dimension fields.
Sorting, pagination, and formatting are not required. The features are controlled via the order, page_limit, page_offset, and precision parameters. They are described in full detail in the Definition section at the end of the documentation for this endpoint.
Filtering
Data filtering may be performed before rows are grouped, and afterwards as well.
It can be done before grouping via the time_window, start_date, end_date, and filter parameters. This provides finer control over what rows contribute to the metric fields of a group.
Filtering can also be done after grouping, and metric calculations via the having parameter.
For more information about the filter and having parameters see the following section.
Predicate Parameters
filter and having are predicate parameters. One of the two parameters is required. The parameters consist of one or more predicates. A predicate has the following format.
a dimension or metric field from the report definition
an operator from the Operators supported in filtering expressions table
one or more values matching the type of field
At least one predicate parameters is required. This is because at least one of the predicates must use one of the access dimension fields in an equality test (operator =).
The filter parameter filters on dimension fields only, while the having parameter may filter by both dimension and metric fields. The filter parameter is applied before rows are grouped, while the having parameter is applied after rows have been grouped, and metrics have been calculated.
The parameter filter is not required if access dimension fields are used in parameter having. Using dimension fields in the having parameter causes those dimension fields to be used in grouping rows.
Operators supported in filtering expressions
Operators
Operation
Field Data Type
=, !=
equality, non-equality check
all
>, <, >=, <=
inequality check
numeric
~, =~
contains, case sensitive
string
=:
contains, case insensitive
string
!~
does not contain, case sensitive
string
!:
does not contain, case insensitive
string
Multiple Predicates
More than one predicate may be specified in a predicate parameter. The predicates need to be joined together with an ampersand (&). The ampersand indicates the predicates are ANDed together. As such, for a record to appear in the results, each predicate must evaluate to true for that record. The following shows an example.
### filtering aggregated rows by metric or dimension fieldshaving=impressions%3E%3D500%26clicks%3C100%26campaign_id%3D12345### (i.e. impressions>=500&clicks<100&campaign_id=12345)### filtering base rows by dimension fieldsfilter=campaign_id%3D12345%26strategy_id%3D98765%2Cstrategy_goal_type%3Dcpc### (i.e. campaign_id=12345&strategy_id=98765&strategy_goal_type=cpc)
Predicates with Multiple Values
A predicate is considered true, if one or more values evaluate as true for the given field and comparison operation. This result is then ANDed with any other predicates that exist at that level of filtering. Values must be separated by commas. The following shows an example.
### filtering records for when campaign_id is 11111, 22222, or 33333 and the campaign_name contains "sell"filter=campaign_id%3D11111%2C22222%2C33333%26campaign_name%7Esell### (i.e. campaign_id=11111,22222,33333&campaign_name~sell)
Encoding Predicates
In order to ensure predicates and values are properly separated, a special encoding is needed for predicate values that contain any of the following characters.
& , " < > = ~ ! :
The encoding is a simple two step process.
Double quotes are doubled.
The resultant value is surrounded in double quotes.
The following shows an example.
Unencoded: Jack & Jill "Of All Trades"
Encoded: "Jack & Jill ""Of All Trades"""
This special encoding may be applied to any value in the predicates. It does not determine the type. The looseness is there to allow for URLs to be more readable. It does however, need to be applied before URL encoding is performed.
Aggregation
Through the dimensions, one can indicate the way the rows must be grouped. One or more dimension fields, may be specified. The order in which the dimension fields are listed is important for the result set.
### group by these fields in this order dimensions=campaign_id%2Ccampaign_name%2Ccampaign_start_date### (i.e. campaign_id,campaign_name,campaign_start_date)
Grouping by metric fields is not allowed. Metric fields are calculated based on the underlying rows of each group. The metrics can be chosen via the metrics parameter.
### calculate these metrics per group dimensions=clicks%2Cimpressions### (i.e. clicks,impressions)
On Success
The system returns an appropriate HTTP return code (2xx or 3xx - see RFC 2616). The response body is CSV-formatted (Content-Type: text/csv), consisting of one header row, and zero or more data rows. The response uses the HTTP 1.1 chunking feature.
A data row will represent a group. It will have a start_date/end_date format, or an interval format. Always use the header line to determine the order of columns, as they may not match the order listed in the parameters.
start_date/end_date Format
two columns of type datetime:
start_date - the start of the time rollup interval (inclusive)
end_date - the end of the time rollup interval (inclusive)
all dimension fields specified in the parameters dimensions
all metric fields specified in the parameter metrics
all fields, dimension or metric, specified in the parameters having and order
Note that the start_date and end_date will cover the whole interval specified by the parameter time_window (or start_date / end_date equivalents), or the intervals generated according to the parameter time_rollup, even though data may not exist for the whole interval.
start_date,end_date,campaign_id,campaign_name,creative_id,creative_name,clicks,impressions,total_spend"2013-05-01","2013-05-22",123456,"My Campaign Nr 10",98765432,"Creative No 12",17701,171981779,45266.65"2013-04-24","2013-04-30",123456,"My Campaign Nr 10",11223344,"Creative Nr Five",4101,45076933,7566.57"2013-04-24","2013-04-30",123456,"My Campaign Nr 10",12121212,"Creative Ten",5220,42592353,6360.86"2013-05-01","2013-05-22",123456,"My Campaign Nr 10",99887766,"Creative One",21912,41691908,61644.34
interval Format
one field of type interval:
interval - the pre-aggregated interval of the group.
all dimension fields specified in the parameters dimensions
all metric fields specified in the parameter metrics
all fields, dimension or metric, specified in the parameters having and order
interval,campaign_id,campaign_name,creative_id,creative_name,clicks,impressions,total_spend7,123456,"My Campaign Nr 10",98765432,"Creative No 12",17701,171981779,45266.657,123456,"My Campaign Nr 10",11223344,"Creative Nr Five",4101,45076933,7566.577,123456,"My Campaign Nr 10",12121212,"Creative Ten",5220,42592353,6360.867,123456,"My Campaign Nr 10",99887766,"Creative One",21912,41691908,61644.34
Predicting the Format
interval based report queries will return the interval format.
datetime based report queries:
using a special time window will return the interval format.
using a normal time window will return the start_date/end_date format.
On Error
On error, an appropriate HTTP status code is returned (4xx or 5xx - see RFC 2616). The response body, which of type XML (Content-Type: text/xml) will contain, at the minimum (see examples below), the root element result, with at least one element named status, which in turn has an attribute named code, and a human readable text. Some error responses also contain an attribute reason, which adds more information regarding the error.
HTTP/1.0 400 Bad RequestContent-Type: text/xml; charset=UTF-8<result> <status code="bad_request" reason="missing_time_window">a time window is required</status></result>
Non-existent entities
HTTP/1.0 404 Not FoundContent-Type: text/xml; charset=UTF-8<result> <entity id="12345" type="campaign" /> <status code="not_found">Entity Not Found</status></result>
Server errors (internal error, request timeout, scheduled maintenance, server overloaded)
HTTP/1.0 500 Internal Server ErrorContent-Type: text/xml; charset=UTF-8<result> <status code="error">Internal Server Error</status></result>
HTTP/1.0 503 Service UnavailableContent-Type: text/xml; charset=UTF-8<result> <status code="unavailable">The server is temporarily unavailable due to maintenance downtime.</status></result>
Path
reportstringrequired
<!-- theme: danger -->
This API is deprecated and will be removed soon
The new API docs can be found here: https://apidocs.mediamath.com/docs/reporting-api-v2
This must be a report discoverable from https://apidocs.mediamath.com/docs/api/0cee9f044b27b-reports-list.
Query
dimensionsstringrequired
Selects the dimension fields to use in grouping rows.
This should be a comma-separated list of dimension field names.
The position of the fields in the output is not guaranteed to match the parameter value. Always use the header line from the response body to identify the position of each column in the output.
metricsstring
Controls the selection of metric fields.
This should be a comma-separated list of metric field names.
The position of the fields in the output is not guaranteed to match the parameter value. Always use the header line from the response body to identify the position of each column in the output.
filterstringrequired
Controls filtering against dimension fields. The filtering is performed before row grouping. See the Predicate Parameters section of https://apidocs.mediamath.com/docs/api/aa580375b0b65-report-data for more information about interpretation and accepted formats.
havingstring
Controls filtering against metric and dimension fields. The filtering is performed after row grouping and metric calculation. See the Predicate Parameters section of https://apidocs.mediamath.com/docs/api/aa580375b0b65-report-data for more information about interpretation and accepted formats.
This should be a comma-separated list of field names. Each field name may optionally be prefixed with a minus sign to indicate descending order. Otherwise, ascending order is assumed.
The first field has the most significance in sorting.
page_limitinteger>= 1
Controls the maximum number of rows of data.
This parameter is required, if page_offset is one or greater.
Default 100
page_offsetinteger>= 0
Controls how many pages to skip.
precisioninteger[ 0 .. 8 ]
Controls how many digits to the right of the decimal places to display for float types.
Default 8
Headers
Cookiestringrequired
_
Default adama_session=<<sessionid>>
Accept-Encoding:string
If the client supports the compression methods also supported by the server (currently gzip and deflate), the response data set (text/csv) will be returned in a compressed format. The metadata and error responses will not be compressed.
In order to receive the data in compressed format, the client must use the HTTP request header Accept-Encoding, and enumerate the preferred compression methods (see RFC 2616). If the header Accept-Encoding is not present in the request, or if it contains only compression methods not supported by the system, the data will be returned in an uncompressed format.
If the data has not changed, the server responds with a 304 Not Modified status code and an empty response body.
If the same request was issued and the data had been updated since the specified time, the server responds with the data requested and a new Last-Modified header.
Mock server https://apidocs.mediamath.com/_mock/apis/reporting-api-v1/{report}
The new API docs can be found here: https://apidocs.mediamath.com/docs/reporting-api-v2
Validating Data Retrieval Requests
Data retrieval requests can be validated and authenticated without actually requesting data, by simply appending a /validate path segment to the URI. Important: The validation process takes into account the current user's permissions. The error responses that are returned in case of validation failure are the same as the ones that would have been returned by the regular API call.
The following shows an example validation request for a request with an erroneous organization_id filtering parameter:
GET /reporting/v1/std/{report}/validate?filter=organization_id%3D12345&dimensions=campaign_id%2Corganization_id&time_window=last_7_days&time_rollup=by_day
HTTP/1.0 404 Not FoundContent-Type: text/xml; charset=UTF-8<?xml version='1.0' ?><result> <entity id="12345" type="organization" /> <status code="not_found">Entity Not Found</status></result>
By contrast, this call shows a validation response for a valid call:
GET /reporting/v1/std/{report}/validate?filter=organization_id%3D12346&dimensions=campaign_id%2Corganization_id&time_window=last_7_days&time_rollup=by_day
This must be a report discoverable from https://apidocs.mediamath.com/docs/api/e39ffafb5c6cb-report-meta.
Query
dimensionsstringrequired
Selects the dimension fields to use in grouping rows.
This should be a comma-separated list of dimension field names.
The position of the fields in the output is not guaranteed to match the parameter value. Always use the header line from the response body to identify the position of each column in the output.
metricsstring
Controls the selection of metric fields.
This should be a comma-separated list of metric field names.
The position of the fields in the output is not guaranteed to match the parameter value. Always use the header line from the response body to identify the position of each column in the output.
filterstringrequired
Controls filtering against dimension fields. The filtering is performed before row grouping. See the Predicate Parameters section of https://apidocs.mediamath.com/docs/api/aa580375b0b65-report-data for more information about interpretation and accepted formats.
havingstring
Controls filtering against metric and dimension fields. The filtering is performed after row grouping and metric calculation. See the Predicate Parameters section of https://apidocs.mediamath.com/docs/api/aa580375b0b65-report-data for more information about interpretation and accepted formats.
This should be a comma-separated list of field names. Each field name may optionally be prefixed with a minus sign to indicate descending order. Otherwise, ascending order is assumed.
The first field has the most significance in sorting.
page_limitinteger>= 1
Controls the maximum number of rows of data.
This parameter is required, if page_offset is one or greater.
Default 100
page_offsetinteger>= 0
Controls how many pages to skip.
precisioninteger[ 0 .. 8 ]
Controls how many digits to the right of the decimal places to display for float types.
Default 8
Headers
Cookiestringrequired
_
Default adama_session=<<sessionid>>
Accept-Encoding:string
If the client supports the compression methods also supported by the server (currently gzip and deflate), the response data set (text/csv) will be returned in a compressed format. The metadata and error responses will not be compressed.
In order to receive the data in compressed format, the client must use the HTTP request header Accept-Encoding, and enumerate the preferred compression methods (see RFC 2616). If the header Accept-Encoding is not present in the request, or if it contains only compression methods not supported by the system, the data will be returned in an uncompressed format.
If the data has not changed, the server responds with a 304 Not Modified status code and an empty response body.
If the same request was issued and the data had been updated since the specified time, the server responds with the data requested and a new Last-Modified header.
Mock server https://apidocs.mediamath.com/_mock/apis/reporting-api-v1/{report}/validate