Campaign Reporting

Scheduled queries for campaign reporting

The aggregated campaign reporting data is generated by scheduled queries run at intervals every day. The data goes into the campaign_reporting dataset in BigQuery, and is used for the campaign reporting page in Mobile Engage campaigns, as well as some billing queries use it now (eg for web-push). We have the following tables in the campaign_reporting dataset:

  • inapp_button_summary

  • inapp_metrics_summary

  • inbox_metrics_summary

  • inbox_undelivered_summary

  • metric_summary (push_metric_summary)

  • undelivered_summary (push_undelivered_summary)

  • web_push_metric_summary

  • web_push_undelivered_summary

  • webchannel_metrics_summary

The name of the scheduled query may slightly differ from those.

Note: in the reporting UI, if today’s date is selected in the range, today’s data is calculated by a dynamic query part which utilizes a BQ table valued function to calculate the most up-to-date metrics from today on the fly. In this query, only the data from yesterday onwards will come from the aggregated tables fed by these scheduled queries.

Deployment of scheduled queries

The scheduled queries for campaign reporting are maintained in the me-bigquery-resources repo. Here they are compiled and deployed using GCS. These queries are then picked up by our ems-tf-mobile-engage-infra repo for deployment via terraformto our environments.

Regenerating campaign reporting data

If you should find the need to regenerate the campaign reporting data for a certain date, you can do this with the me-cli tool now. Use any of the commands below to start the wizard and follow the instructions to select the date range, customers and metrics you want to regenerate the data for.

me-cli campaign-summary
me-cli campaign
me-cli campaign-reporting

You can also provide the parameters directly in the command. You must also specify an action (regenerate or purge) as well as a metric type at minimum.

If you supply regenerate as action, the data will first be purged and then re-generated (where the purge can be skipped with a --no-purge flag). If you supply purge as action, the data will only be purged and not re-generated.

Available metric types are: push, push-undelivered, inbox, inbox-undelivered, web-push, web-push-undelivered, inapp, inapp-button, web-channel. You can only regenerate all metrics for the selected metric type/channel.

Available parameters are:

-f, --from <date>          Start date for regeneration in format YYYY-MM-DD (optional, default: yesterday)
-t, --to <date>            End date for regeneration in format YYYY-MM-DD (optional, default: today)
-c, --customers <ids>      Comma separated list of customer ids to regenerate data for (optional, default: all customers)
-p, --project <project>    Google Cloud project to target (optional, default: production)
-n, --no-purge             If set, the existing data will not be purged before regeneration (optional, default: false)
-x, --print-command        If set, the command that would be executed will be printed but not executed (optional, default: false)

This information is also available in the help text of the command in me-cli.

Here are some examples of how to use the command with parameters:

me-cli campaign-summary regenerate web-push
me-cli campaign-summary regenerate web-push-undelivered

me-cli campaign-summary regenerate push --from 2026-03-01 --to 2026-03-02 -customers 1234,5678 -project staging
me-cli campaign-summary regenerate inbox -f 2026-03-01 -t 2026-03-02 -p staging
me-cli campaign-summary regenerate push  -f 2026-03-01 -t 2026-03-02 -c 1234,5678
me-cli campaign-summary regenerate push  -f 2026-03-01 -t 2026-03-02 --no-purge
me-cli campaign-summary regenerate push  -f 2026-03-01 -t 2026-03-02 --print-command

Note that regenerating the data in this way might lead to different numbers than before. Since the source data is 'alive', meaning late messages or data deletion requests might alter or add to the data that we aggregate from. So if you regenerate the data for a past date, you might end up with different numbers than before. This is expected and not necessarily an indication that something went wrong.