Performance Analytics GCP Migration

Background

In March 2018, we moved our entire messaging architecture to Google Cloud Platform (GCP). Turns out that sending billions of notifications per day across multiple channels and providing reliable engagement and event data back to customers is pretty complex, and we decided it was time to move our service infrastructure to the cloud. There were many reasons for this decision, but not least among them were:

1. Focusing our engineering resources on product development/optimization and improving engineers’ job satisfaction.
2. Taking advantage of the cutting-edge technologies that come with a cloud provider.
3. Enabling easier global expansion of the Airship platform, e.g., EUCS.

We chose GCP as a best-in-class Infrastructure as a Service provider for this undertaking. Since then, the benefits we have seen in terms of message throughput, reliability and uptime have proven worth the effort manyfold, exceeding our own expectations for the goals stated above. This move is a continuation of those efforts.

How will this change affect me?

In the main, you will see faster queries, and more accurate reporting of data related to the state of tags on users’ Channels. Query times will continue to improve as we further optimize, now that the migration is complete.

You may also notice some differences in number counts and custom queries. Do not be alarmed if so. The numbers are based on the same raw data sources, but there are some differences in the way these values are computed that will appear in reports. We will explain these differences in the sections below.

More Frequent Data Loading

Data is now being loaded more frequently into Performance Analytics. The primary effect that you will notice with this change is that reports with windows that include the last 24 hours will have more data, and therefore counts will generally be higher.

More frequent loading also means that you may see some more apparent variation over the course of 24 hours as delayed events trickle in from Channels. Keep in mind that because of the nature of mobile connectivity, the first 24 hours of data collection are always the most volatile in terms of analyzing events. Our data services are built to let lagging events come in when Channels come back online. As a best practice, you should wait at least 24 hours before making decisions about your data, to allow trailing data to fill in.

Also related to the increased load frequency: any metrics that use the current time in a computation, such as retention, e.g., previous 7 days, will have higher values now because there is more data available.

Improved Channel State Management

We have improved the underlying mechanism for determining the presence or absence of a tag on a user’s Channel within the bounds of your query. Our previous system had certain scenarios in which an UNINSTALL event did not also trigger a tag REMOVE event, which in some cases led to an overstatement of the actual number of Channels with the given tag.

Incidences of this behavior have been reduced greatly in the new implementation, and we will continue to work to reduce such occurrences in the future.

Date Range Queries

In rare instances, you may see errors where custom date range filters are applied to a report. This is due to the different ways GCP and our previous service compute time periods based on the filters provided. The major difference is that GCP requires explicit dates between which to compute the results.

For example, if your Occurred Date filter is set to is before, and you are seeing an error for this filter, you should change the setting from:

• is before

to:

• is in range <date prior to your retention start> and <today’s date>

See the table below for other potential date filters that might be causing errors. Please contact Airship Support  if you encounter any other issues.