How to load data from Mandrill to Google BigQuery

How to Extract my Mandrill data?

There are two main methods to get our data that come from Mandrill, the first one is to pull data out from it and the second one is to ask Mandrill to push data to us whenever something of importance happens. We will see the difference between these two solutions and how we can access data using both of them.

To pull data by a Mandrill source, we need to access its HTTP API. As a Web API following the RESTful architecture principles, it can be accessed through HTTP. As a RESTful API, interacting with it can be achieved by using tools like CURL or Postman or by using HTTP clients for your favorite language or framework. A few suggestions:

Mandrill maintains a number of officially supported clients or SDKs that you can use with your favorite language to access it without having to mess with the raw underlying HTTP calls. These are the following:

There are also a number of unofficial clients that you can use if you prefer. The complete list can be found here.

In this post, we will consider the more generic case of accessing the HTTP endpoints directly for our examples, but of course, you are free to use the client of your choice for your project.

Mandrill API Authentication

In order to use the Mandrill API, you first have to generate an API key through your MandrillApp account. When you have created the key you can use it to access the API. You can actually have multiple keys per account, something that adds versatility to the platform. In most cases with the Mandrill API, you make a POST call to access an endpoint with a JSON body containing the access key.

Mandrill rate limiting

API rate limiting with Mandrill is a bit of a more complicated matter than in most cases of APIs out there. The reason is that Mandrill is mainly an SMTP as a service platform. In most cases, when we make a call to its API we do it in order to send an e-mail to someone, so rate-limiting in the typical sense that we find it in web APIs does not apply in Mandrill. What is actually happening is that every Mandrill account has a reputation and an hourly quota. The main reason that rate limiting is a bit more complicated in Mandrill is that they need to take special care of pointing out and handling potential spammers. So the hourly quota is affected by your reputation, if for example, you have a poor reputation then Mandrill will reduce the number of e-mails and consequently the API calls that you can do on a per hour basis. On the contrary, if you have an excellent reputation you will be able to make more calls. Free accounts can send up to 25 emails per hour. If you want to find your hourly quota and reputation, you will have to check your Dashboard in MandrillApp.

Endpoints and available resources

Mandrill exposes the following endpoints:

Users: Information about your account, for example here you can validate that your API key is valid.
This endpoint is used to send messages through the Mandrill API.
Information and operation about user defined tags.
Rejects. Manage your email rejection list.
Whitelists. Manage your rejection whitelists.
Senders. Manage senders associated with your Mandrill account.
Get information about the URLs that are included in your e-mails.
Manage e-mail templates.
Webhooks. Manage webhooks for your account.
Subaccounts. Manage subaccounts.
Information about domains that have been configured for inbound delivery.
Run export jobs to retrieve data by a Mandrill account you own.
IPs. Information and operations about your dedicated IPs.
Information and operations about your custom metadata fields indexed for the account.

The above endpoints define the complete set of operations that we perform with Mandrill. In our case, we care mainly about what data we can export so that we will work with the export endpoint. Export jobs can be executed for the following data:

Export your rejection blacklist.
Export your rejection whitelist.
Export your activity history.

We assume that you would like to export your activity data. To do that, you need to perform a POST request to the following endpoint:

JAVASCRIPT
/exports/activity.json

Keep in mind that the base URL might change depending on the warehouse where your application is hosted. For this reason, we will mention only the endpoints, and you will have to prepend the base URL for your case.

The body that we should post to the above end-point should look like this.

JAVASCRIPT
{
   "key": "example key",
   "notify_email": "notify_email@example.com",
   "date_from": "2013-01-01 12:53:01",
   "date_to": "2013-01-06 13:42:18",
   "tags": [
       "example-tag"
   ],
   "senders": [
       "test@example.com"
   ],
   "states": [
       "sent"
   ],
   "api_keys": [
       "ONzNrsmbtNXoIKyfPmjnig"
   ]
}

We need to provide our API key, and we can also define a date range from which the API will collect data. We can filter even more the data we will get back by requesting specific tags or senders and states if we want.

The results will include fields about:

Date
Email address
Sender
Subject
Status
Tags
Opens
Clicks
bounce details

When the export job finishes, the data will be available through a URL in a gziped format. Keep in mind that you will have to poll the Exports endpoint to figure out when the job is finished and get the exact url from which you will get the data. To do that you need to perform a POST request to the following end-point:

JSON
/exports/info.json

The body of the POST request should be a JSON document containing your api-key. You will get back a result like the following:

JAVASCRIPT
{
   "id": "2013-01-01 12:20:28.13842",
   "created_at": "2013-01-01 12:30:28",
   "type": "activity",
   "finished_at": "2013-01-01 12:35:52",
   "state": "working",
   "result_url": "https://exports.mandrillapp.com/example/export.zip"
}

As you can see from the response, we get a URL from which we can fetch any data and information about the completion or not of the job. If the state of the job is complete then we can safely download them and further process it.

Another way of getting data using the Mandrill API is to ask it to push our system events every time something important happens. To do that, we need to set up webhooks on our system and provide the URLs to Mandrill. The platform will POST data in JSON format to these URLs every time an event is triggered. The good thing about this mechanism is that we can have every data as soon as possible in our system for analysis.

Every Mandrill webhook uses the same general data format, regardless of the event type. The webhook request is a standard POST request with a single parameter (currently) – mandrill_events.

There are three types of webhooks that Mandrill currently POSTs: Message webhooks (such as when a message is sent, opened, clicked, rejected, deferred, or bounced), Sync webhooks, and Inbound webhooks.

The mandrill_events parameter contains a JSON-encoded array of webhook events, up to a maximum of 1000 events. Each element in the array is a single event, such as an open, click, or blacklist sync event. For examples of each type of event and a description of the keys, select the type of events you’ll be processing:

Message events (send, deferral, hard-bounce, soft-bounce, open, click, spam, unsub, reject)
Sync events (whitelist of blacklist sync)
Inbound messages

For more information about Webhooks, you can check here.

How can I prepare my data to be sent from Mandrill to Google BigQuery?

Before you load your data into BigQuery, you should make sure that it is presented in a format supported by it, so for example, if the API you use to pull data returns XML, you have first to transform it into a serialization that BigQuery understands. Currently, two data formats are supported:

CSV, and
JSON

You also need to make sure that the data types you are using are the ones supported by BigQuery, which are the following:

STRING
INTEGER
FLOAT
BOOLEAN
RECORD
TIMESTAMP

For more information, please check the Preparing Data for BigQuery page on the documentation.

Load Data from Mandrill to Google BigQuery

If you want to load any data from Mandrill to Google BigQuery, you have to use one of the following supported data sources.

Google Cloud Storage
Sent data directly to BigQuery with a POST request
Google Cloud Datastore Backup
Streaming insert
App Engine log files
Cloud Storage logs

From the above list of sources, 5 and 6 are not applicable in our case.

For Google Cloud Storage, you first have to load your data into it. There are a few options on how to do this. For example, you can use the console directly as described here, and do not forget to follow the best practices. Another option is to post your data through the JSON API. As we see again, APIs play an important role in both the extraction and the loading of data into our data warehouse. It’s just a matter of one HTTP POST request using a tool like CURL or Postman in its simplest case. It should look like the following example.

JAVASCRIPT
POST /upload/storage/v1/b/myBucket/o?uploadType=media&name=myObject HTTP/1.1 Host: www.googleapis.com Content-Type: application/text Content-Length: number_of_bytes_in_file Authorization: Bearer your_auth_token your Mandrill data

and if everything went ok, you should get something like the following as a response from the server:

JAVASCRIPT
HTTP/1.1 200 Content-Type: application/json { "name": "myObject" }

Working with Curl or Postman is good only for testing. If you would like to automate the process of loading your data into Google Bigquery, you should write some code to send your data to Google Cloud Storage. In case you are developing on the Google App Engine, you can use the library that is available for the languages that are supported by it:

If you are using one of the above languages and are not coding for the Google App Engine, you can access the Storage you have on Cloud from your environment. Interacting such a feature-rich product like Google Cloud Storage can become quite complicated depending on your use case. For more details on the different options that exist, you can check Google Cloud Storage documentation. If you are looking for a less engaged and more neutral way of using Cloud Storage, you can consider a solution like RudderStack.

After you have loaded your data into Google Storage on Cloud, you have to create a Load Job for BigQuery actually to load every data into it, this Job should point to the source data in Cloud Storage that have to be imported, this happens by providing source URIs that point to the appropriate objects.

The previous method described a POST request to the Google Cloud Storage API to store data there and then load it into BigQuery. Another way to go is to make a direct HTTP POST request to BigQuery with any data you would like to query. This approach is similar to how we loaded our data to Google Storage you own on Cloud through the JSON API, but it uses the appropriate end-points of BigQuery to load data there directly. The way to interact with it is quite similar, for more information can be found on the Google BigQuery API Reference and on the page that describes how to load data into BigQuery using POST. You can interact with it using the HTTP client library of the language or framework of your choice. A few options are:

The best way to load data from Mandrill to Google BigQuery

So far, we just scraped the surface of what you can do with Google BigQuery and how to load data into it. Things can get even more complicated if you want to integrate data coming from different sources.

Are you striving to achieve results right now?

Instead of writing, hosting, and maintaining a flexible data infrastructure, use RudderStack that can handle everything automatically for you.

RudderStack, with one click, integrates with sources or services, creates analytics-ready data, and syncs your Mandrill to Google BigQuery right away.

Don't want to go through the pain of direct integration?

RudderStack's Mandrill integration

makes it easy to send data from Mandrill to Google BigQuery.