Export

Page Contents

Export Steps
Webhook Steps
Webhook Transformation Service
How to create a Webhook Transformation Service
How to create the Webhook with WTS
How to set up the Script
Details about script
API
Activity Export
Reporter Module

Your Agillic instance logs data at a granular level for all activities executed in the platform, and of course provides access to any data structure you may have imported yourself. To have a full data flow to the rest of your data ecosystem, it is likely you will need to export data from Agillic.

Agillic has many ways to automate the export of data, with each methods covering all conceivable data types, frequency requirements, and formats. Manual exports are also supported.

Export Steps (Via Flow)
Webhook Steps (Via Flow)
API
Activity Export
Reporter

Let us know if you would like to see other export methods and features by sending an email to product.feedback@agillic.com

Export Steps

Export Steps are set up in flows (Export Flows), which can be scheduled or triggered to do bulk exports of data for a segment of your recipients.

Flows can be triggered by events, scheduled on an interval, or even executed with our Flows API from an external system.

Export Steps specifically consist of an Export Template, which defines what data is should be sent, and an Export Profile, which defines where it should be sent. Export Profiles can also be used on Activity Exports.

Export Templates support generating export files with:

Person Data
One-To-Many Tables
All Lookup Types
Subset of Activity Data

Data Types and multiple tables of the same type cannot be mixed within a single file. But you can have an export flow with multiple export steps, with multiple templates to export multiple files, each with a different model.

Export Profiles can send data to your instance’s WebDav or an external FTP or SFTP server.

Webhook Steps

Webhook Steps are set up in flows, which can be scheduled or triggered to make HTTP calls containing recipient data to other parts of your data ecosystem, for a segment of your recipients.

Flows can be triggered by events, scheduled on an interval, or even executed with our Flows API from an external system.

Webhook Steps require a Webhook, which defines what data is put into the default-structured JSON body.

Webhooks have access to the following data structures:

Person Data
One-To-Many Tables
Global Data
Static Data (Key/Value pairs)

The sent JSON body can be re-written in any desired JSON format with a Webhook Transformation Script (WTS). A WTS is applied to a Webhook, and can be applied to a Webhook Step, just like a Webhook without a WTS applied.

Webhook Steps are set up in flows, which can be scheduled or triggered for a segment of your recipients.

Webhook Transformation Service

A Webhook Transformation Service allows you to change the format of the standard JSON body sent with a Webhook’s HTTP call, to match any requirements an external system may have. Each Webhook Transformation Service requires a Webhook to define which data fields are available to the script, and ultimately re-structured to be sent for the recipient. Each Webhook Transformation Service is created directly in the Agillic UI.

Contact your Agillic responsible to learn how to get access to the Agillic UI

How to create a Webhook Transformation Service

Navigate the to the Administration module, under ‘Integrations’ select ‘Webhook Transformation Service’
Check the option for ‘Enabled Webhook Transformation Service’
Click the Plus icon to add a new Webhook Transformation Service
Name the Transformation Service (note this for later)
Enter a description (optional)
Enter the URL the Webhook should call
Authenticate the call if needed. This is usually done with a basic auth token
Save the service

How to create the Webhook with WTS

Now navigate to the Data module and select ‘Webhooks’
Create a new Webhook and name it
Click the check box to use an already created transformation service, and select it from the list
Select what data to add for the Webhook (Person Data/One-to-Many Data/Static Data)
Save the Webhook

How to set up the Script

In order to correctly convert the default data format into another, a script must be made utilizing the data added to the webhook in the previous steps. To do so, return to the Webhook Transformation Service UI and open the script editor by clicking < >.

Select the Webhook already created in the dropdown in the upper right corner, to show an example of the format
Add the Transformation Script to the left column (see details below to write a WTS script)
Verify the transformed format is being shown correctly in the lower right corner
Scroll down and save the Transformation script

The script is made using Javascript. The default format of the Agillic Webhook looks like:

{
  "personData" : {
    "EMAIL_PERMISSION" : false,
    "FIRSTNAME" : "TEST",
    "FAVOURITE_CANDY_STORE" : "TEST",
    "FAVOURITE_CANDY_TYPE" : "TEST",
    "OPTIMISED_SEND_HOUR" : 123,
    "EMAIL" : "TEST",
    "BIRTHDAY" : "01.01.2017",
    "QUESTIONNAIRE_UPDATED" : "01.01.2017 00:00:00"
  },
  "otmData" : {
    "PURCHASES" : {
      "CATEGORY" : "TEST",
      "STORE" : "TEST",
      "TIME" : "01.01.2017 00:00:00",
      "ID" : 123,
      "NAME" : "TEST"
    }
  },
  "constantData" : {
    "source" : "agillic"
  }
}

The Transformation script could look like:

function transform(jsonString, factory) {
    var jsonObj = JSON.parse(jsonString);
    var res = [];
    for (var pd in jsonObj.personData) {
        var jso = {};
        jso[pd] = jsonObj.personData[pd];
        var def = factory.bodyPost(JSON.stringify(jso));
        res.push(def);
    }
    return res;
}
 
function validate(code, body) {
    return -2;
}

The finished format would then result in the following Webhook:

POST {"EMAIL_PERMISSION":false}

Details about script

Transform method
The transform method is where you take the json object you posted, and turn it into the relevant outgoing call.

The call takes as parameters a string, which is the json object we received, and a “factory” (see below). It should return a list of outgoing calls to perform. The list can be empty or null which is then treated as no calls should be made.

To build the definition of the call you should use the factory, which currently makes the following three methods available:

bodyPost(body) – taking a json string as parameter and defining a call as a POST with a json body
bodyPut(body) – taking a json string as parameter and defining a call as a PUT with a json body
formPost(map) – taking a map of string -> string as a parameter and defining the call as POST with content-type application/x-www-form-urlencoded

The returned object is the call definition and can be returned directly, however, there are also a few more methods on that one for a bit more customization.

withHeader(name,value) – instructs us to set a header on the call. There can be multiple headers.
withParameter(name,value) – only relevant when doing formPosts – add another parameter to the map for the body

Replacement parameters in the URL
Say the endpoint you want to call uses a REST like approach to the urls so you need to make a PUT call to:

https://example.com/update/<userid>

Or consider the possibility that the endpoint takes the settings as query parameters like:

https://example.com/permission?type=<type>&allow=<true/false>

To achieve this, we support replacement of parameters in URLs – so depending on the desired format, when you define the endpoint, you would either write:

https://example.com/update/%%uid%%

https://example.com/permission?type=%%type%%&allow=%%allow%%

You can use the following method on the returned definition object:

withRequestReplacement(name,value)
name is the parameter to be replaced in the link, denoted by encapsulation with %%
value is the value that you would like to assign to the parameter

These will be replaced when we build the final call.

Validate method
When we make a call to the final endpoint we need a way to see if the call was successful, this is where the validate method comes in. The method is given the http response code and the body of the response and can then decide what the outcome of the call was.

This method should return:

A positive number if the call was successful
A negative number if the call failed and should not be retried
Zero if the call failed but the call should be retried.

The zero is to allow you to configure logic that deals with retries or a remote service being down. The retry logic is fixed and is currently re-trying five times using exponential backoff with the first retry after 10 seconds, the last retry will be performed after approximately five minutes. Please only use retry in cases where it’s likely a second attempt will result in a different outcome. Please note that the transform method is called only before the first attempt to make the call, i.e you cannot alter the url before the retries are made.

While the validate method is not mandatory, if it’s not implemented all calls are treated as successful.

Locate the data type you wish to export and see the export methods available:

Type	Agillic UI	API	Webhook
Person Data	Yes	Yes	Yes
Promotions	No	Yes	No
One to Many Data	Yes	Yes	Yes
Global Data	No	No	Yes
Global Data Table	Yes	Yes	No
Activity Data	Yes	Yes (tracking data)	No

API

The Rest APIs can of course also be used to provide your Agillic Instance’s data to your other infrastructure components. Primarily done with calls using the GET HTTP verb, you can access

You can also export your instance’s configured data structure by using our Discovery API. This can be especially helpful when making a connector to Agillic, and want programmatic access to detailed information on the instance’s data structures, types, and restrictions.

Get a general introduction to our RESTful APIs!

Activity Export

Activity Exports provide detailed information on the activities executed on your Agillic instance. An activity data zip file is produced for your instances entire recipient database, over the specified period, for the specified channels, and sent to the destination provided in the Export Profiles.

Activity Exports can contain data describing activity in any set of the following channels:

Email
Transactional Email
SMS
Event
Promotion
Inbound SMS
Pages
Prints
Push Notifications
Web Tracking Data
Facebook Custom Audience
Google Customer Match

See how to configure an Activity Export, and understand the data formats.

There are more details here as well.

This data is generally used for BI tasks, and Agillic utilises this same data to display results in the reports you build in our Reporter Module.

Reporter Module

In the Reporter Module you can build dashboards and reports which display results of your marketing campaigns. While some reports contain aggregated results (click/open rate, etc), some can be configured to segment recipients who match certain criteria, and display different metrics, which can be be exported manually.

Check our Knowledge Base guides on the Reporter, and test out making reports on different activity data, switching between graph types, and exporting those results through your browser.