When you load the PHP file in your browser, you will see the following output: ET _ Post Object ( [status] => 1 [code] => 200 [message] => [results] => Array ( [0] => stdClass Object ( [StatusCode] => OK
[StatusMessage] => Created DataExtensionObject [OrdinalID] => 0
[NewID] => 0
[Object] => stdClass Object (
[PartnerKey] => [ObjectID] =>
[CustomerKey] => subscribers [Properties] => stdClass Object ( [Property] => Array ( [0] => stdClass Object ( [Name] => EmailAddress [Value] =>
YOUR _ EMAIL _ ADDRESS
)
[1] => stdClass Object (
[Name] => FirstName
[Value] =>
YOUR _ FIRST _ NAME ) ) ) ) ) ) [request _ id] => [moreResults] => )
This output displays a typical response to a PHP client library operation. For now, just note that the call succeeded as indicated by StatusCode and StatusMessage.
38
Go back to the Email application and verify the row added successfully by navigating to the Data Extensions screen and clicking the data extension. Click the Records tab to view the data (Figure 18).
Figure 18: Adding a row to the data extension via the PHP client library
To highlight the similar patterns employed by the different client libraries, the following Java code is equivalent to the PHP code we used to add the row to the data extension:
public class DataExtensionAddRow { public static void main(String args[]) throws ETSdkException
{
ETClient client = new ETClient();
ETFilter filter = new ETSimpleFilter(“CustomerKey”,
ETFilterOperators.EQUALS, “subscribers”);
ETDataExtension dataExtension = client.retrieveDataExtension (filter);
ETDataExtensionRow row = new ETDataExtensionRow(); row.setColumn(“EmailAddress”, “YOUR _ EMAIL _ ADDRESS”); row.setColumn(“FirstName”, “YOUR _ FIRST _ NAME”);
dataExtension.insert(row); }
}
Using the API Directly
If you are using a language or platform for which a client library is not available or a client library is otherwise not a viable solution, you can use the API directly rather than going through a client library. This section shows you how to do that.
Getting an Access Token
The first step in any API-based integration is getting an access token you will use to authenticate other API calls. To get an access token, use the Fuel authentication service. The code sample below demonstrates how to use an HTTP POST request to acquire an access token:
POST https://auth.exacttargetapis.com/v1/requestToken Content-Type: application/json
{
“clientId”: “YOUR _ CLIENT _ ID _ FROM _ APP _ CENTER”,
“clientSecret”: “YOUR _ CLIENT _ SECRET _ FROM _ APP _ CENTER” } 200 OK { “accessToken”: “p3sygbfr3t7z94f7wv4czxtw”, “expiresIn”: 3600, “refreshToken”: “hu3kyjqt4r7wpwrkbkjvpwpu” }
The access token is returned in the accessToken property. You can use this token to authenticate other API calls by specifying this value via the Authorization header field with the Bearer HTTP authorization scheme:
GET https://www.exacttargetapis.com/platform/v1/endpoints Accept: application/json
Authorization: Bearer p3sygbfr3t7z94f7wv4czxtw
You can use Fuel access tokens to authenticate with the ExactTarget SOAP API as well. The following example use the same access token to authenticate with the SOAP API:
<s:Envelope xmlns:s=”http://schemas.xmlsoap.org/soap/envelope/”> <s:Header> <h:fueloauth xmlns=”http://exacttarget.com” xmlns:h=”http://exacttarget.com”> p3sygbfr3t7z94f7wv4czxtw </h:fueloauth> </s:Header> [...] </s:Envelope>
40
Refreshing the Access Token
Note the expiresIn and refreshToken properties in the HTTP response to the requestToken API call. Fuel access tokens expire one hour after they are issued. If you attempt to use an expired token, you will receive a 401 Unauthorized HTTP response. If this happens, you will need to refresh your access token. To do that, add the refresh token from your initial call to your next call:
POST https://auth.exacttargetapis.com/v1/requestToken Content-Type: application/json
{
“clientId”: “YOUR _ CLIENT _ ID _ FROM _ APP _ CENTER”,
“clientSecret”: “YOUR _ CLIENT _ SECRET _ FROM _ APP _ CENTER”, “refreshToken”: “hu3kyjqt4r7wpwrkbkjvpwpu”
}
Important considerations when using the API directly
There are two important considerations to keep in mind if you use the API directly and do your own OAuth token management rather than using the SDKs.
First of all, you should NOT request a new token for every API call you make—each token is good for an hour and should be reused. Making two API calls for every one operation is inefficient and may result in throttling.
Secondly, and we cannot say this enough, be careful where you store your client secret. In particular, you should NOT store your client secret in a mobile application because a mobile device is not a secure environment; it is recommended that you utilize an Authorization Code or Implicit Grant OAuth flow instead.
We are now ready to build our first customer journey. As mentioned in the introduction, we will be playing the role of a fictional wearable device company wanting to drive post-purchase customer engagement by encouraging new customers to download our mobile app and, once installed, encourage consistent usage of it.
We want to do this because we know the more engaged our customers are, the more likely it will be that they will continue to use our product regularly; and that the more they use our product regularly, the more likely it will be that they will buy the next version. This is a good example of a “For App” strategy as described in the section A For App Strategy. Let’s build out our fictional scenario. We offer our wearable in retail outlets as well as online. When customers purchase our product, they create an account in our system their product synchronizes with, making their data available to them in the cloud so they can access it both on our web site and on a mobile app we offer free in popular app stores. The signup process involves supplying an email address, which is a very common requirement for “forgot my password” reasons. It is that email address that provides us with the opportunity to make our first customer touchpoint, and it is that customer touchpoint that initiates the overall customer journey.
Once the account has been created, we’ll fire an event into the Journey Builder engine that begins a simple drip campaign designed to get the customer to install the mobile app. The first step of the drip campaign is to send an email to the customer thanking them for signing up. We’ll use that email send to encourage new customers to download the mobile app, including a link to the app store to make it as easy as possible for them to do that as well as to track who clicks through. Next, we’ll wait a few days, and if the customer hasn’t yet installed the app, we’ll send them another email with an incentive to do so: 20% off renewal next year.
Once the app is installed, we’ll use the Journey Builder Apps for SDK to more deeply engage with our customers through push and in-app messages. In this chapter …
• Journey Builder Basic Concepts
• Creating Your Content in the Email App
• Setting Up the Contact Model Using Contact Builder
• Creating your first interaction in Journey Builder
42
Journey Builder Basic Concepts
Before proceeding, it will be very helpful to have an understanding of how Journey Builder works and its basic concepts.
In Journey Builder, an interaction is a workflow comprised of an interconnected series of activities and waits. Activities can be outbound message actions such as Send Email or Send SMS or control flow actions such as Decision Split or Engagement Split that send the interaction down one path or another based on a specified condition being met (e.g., the email sent in a previous step of the interaction has been opened). Waits suspend the interaction for a specified period of time (e.g., “wait two days, then perform the next activity”). Optionally, an interaction can have a stated goal (e.g., “I want 80% of the population to install the mobile app”).
The interaction begins executing when an event gets fired (e.g., the customer has just registered their product) and a trigger condition is met (e.g., the customer has not yet installed the mobile app). Once the interaction begins executing, customers that meet the trigger condition move systematically through the interaction according to its activities and waits. Customers leave the interaction once they have reached the final activity or the goal of the interaction has been met (if the goal is configured to cause the customer to leave the interaction once it has been met).
Journey Builder uses contacts to represent customers and store customer data. Contacts represent a single view of your customers, consolidating information gathered from multiple sources into a single place and making that information actionable in your customer journeys. You can associate any type of data with a contact, including address information that spans multiple channels (email address, mobile number, etc.), interests and preferences, engagement history (opens, clicks, page views, etc.), and data from third-party sources (demographic information, purchase history, etc.).
In addition to the standard activities available to you in Journey Builder, you can build your own activities as well, either custom for your organization or as an ISV for the ExactTarget HubExchange marketplace. How to build your own activites is beyond the scope of this book—see http://code.exacttarget.com/ app-development/journey-builder-development/ for more information on building your own Journey Builder activities.
Before we get into Journey Builder, we need to prepare the content assets we’re going to be using in the email that will initiate the customer journey.
Creating Your Content in the Email App
First, create the emails to send in the interaction using the same flow used in Sending Your First Email. Create two emails: A message thanking the customer for purchasing the wearable with a link to the app, and the other reminding the customer to install the app and offering them an incentive to do so. We’ll be sending the second message in the event they don’t install the app after receiving the first message using a typical drip campaign flow.