#CNX14 - Dive Deep into the ExactTarget Fuel APIs

Editor's Notes

• #2: Unicorn Story
• #10: When you’re at Code@, make sure to Download an SDK in the flavor of your choice. You’ll also want to Register for an account on AppCenter.
• #11: In this section, we’ll walk through an example that leverages the APIs as well as the SDKs, to accomplish a real world scenario. This scenario is an abbreviated example of the exercises in the Journey Builder for Apps book. You can pick up a free copy in the dev zone.
• #12: This Scenario should sound familiar, it’s the same use case described in yesterday’s keynote. We’re going to outline an example of how FitBit could use Journey Builder to Drive Installation of their mobile app for new users.
• #13: First, we’d like to introduce something new for you, the developers. This week at connections, we’ve launched Developer Edition, which allows any developer to begin developing applications on the platform for FREE. Log in and break stuff, have a good time.
• #14: After you’ve Created your Developer and AppCenter accounts, you’re going to want to create your first application. This application will allow you to make API calls.
• #15: Make sure to select API Integration for Application Type.
• #16: And then Record your ClientID and Secret
• #17: You’ll use your clientId and clientSecret to configure the SDK, as well as to make API calls to the platform.
• #18: You can download the following examples on github at this URL. I’ll give you a moment to take a photo or punch in the URL.
• #19: Next, we’ll model your customer model into the Marketing Cloud Platform. Here, we’re defining a relational table, which we call a Data Extension. DataExtensionName would be the name of your Customer Model CustomerKey is an identifier you can use to refer to this table by, IsSendable means this table will contain email addresses that you’d like to send email to, which are defined in SendableDataExtensionField and SendableSubscriberField, below.
• #20: After we configure the metadata of the Data Extension, we’ll define the columns. In this example, we’ll keep it simple: Email Address, Name and a flag to determine if the customer has installed the mobile app. Notice that we’re setting the EmailAddress as the primary key, which is required.
• #21: After we’ve defined our data extension, we’ll use the SDK to begin populating it with our Data. In thissimple example, we’re uploading our Customer’s names and email addresses, but this could easily grow to accommodate much more complex data.
• #22: Finally, we’ll use the SDK to create the emails we’ll be sending as part of our Drip campaign. Customer Key is the Primary Key you can refer to the email by, IsHTMLPaste refers to the type of email you’ve created. In this case, you simply populate the Email Body with the HTML body specified above.
• #24: Now that we’ve defined our data model, and imported it into the Marketing Cloud, we can now map our data to the Contact model. This mapping allows us to strongly enforce a 1:1 customer model, guaranteeing that you’re always sending data to customers in the right channel at the right time. Because this is an email-based journey, we’re mapping the Customer’s Contact Key to their email address.
• #25: Next, we’ll update the Channel Address Order, specifying that the email address in the Data Extension is also an available channel for communication.
• #26: After we’ve Extended the Contact Model, we’re ready to begin building our Customer Journey. We’ll start by Creating a Trigger – an entry-point into a customer Journey.
• #27: For this journey, we’re interested in driving mobile app installations. We’ll define our filter to only trigger if the flag on their account indicates that they haven’t installed our App yet. In this case, we’re starting the journey for both the case where we’re not sure , or if they’ve explicitly not installed the app.
• #28: After we’ve defined our filter, it’s time to build the Drip campaign on the Journey Builder Canvas. Here, if the Filter conditions are met, we’ll define 2 emails to be sent. The first is the welcome email, welcoming the customer to the platform, and encouraging them to download and install the mobile app. If after 3 days, the customer still hasn’t installed the application, we’ll send a second reminder email.
• #29: A key part of this journey is that we don’t want to message the customer if they’ve already installed the application. Journey Builder gives us a great tool to manage this evaluation, called the Decision Split. The decision split can be compared to an if-then statement – it evaluates a condition, and performs an action based upon that result. Here, we’re evaluating whether the user has installed the application.
• #30: A key part of this journey is that we don’t want to message the customer if they’ve already installed the application. Journey Builder gives us a great tool to manage this evaluation, called the Decision Split. The decision split can be compared to an if-then statement – it evaluates a condition, and performs an action based upon that result. Here, we’re evaluating whether the user has installed the application.
• #31: We’re almost complete. After Activating and saving the Journey, we’re now ready to begin guiding customers through it’s steps. In order to execute this Journey, we’ll need to invoke it via the API. To do so, we’ll need to know our Event Definition Key. We’ll use this key to indicate that a journey is ready to be evaluated, and potentially executed. You can access the Event Definition Key by clicking “Trigger Administration” on the Journey Builder dashboard.
• #32: The functionality to execute a Journey hasn’t yet made it to all the SDKs, so we’re going to use the REST API natively. Before we perform the REST API Call to execute our Journey, we’ll need to get an authorization token. If we were using the SDK, this would be handled for us. In this example, we POST our clientID and Secret to the requestToken endpoint, and it will return an accessToken, valid for an hour. Please note that you’ll only need to retrieve this token if it has expired, it’s not necessary to retrieve a fresh token before each call.
• #33: Armed with our EventDefinitionKey, and our Auth Token, we can now execute the Journey. We POST a call to the events endpoint, indicating which user we’d like to evaluate the journey for. In this case We specify both the ContactKey which we mapped earlier, and the email address for the customer. In this case, these happen to be identical. After the call is made, Journey Builder will evalute The filter we defined, and if the criteria are met, will initiate the customer’s journey. The welcome email will be sent, encouraging the customer to install the mobile app. 3 days later, if the customer Still hasn’t installed the app, a second attempt will be made.
• #34: That’s it, thanks for participating! To recap, Using the SOAP and REST APIs, as well as our SDKs, we helped drive a journey to encourage new Fitbit users to download their mobile application. We… 1-5 It’s not difficult to imagine extending that journey, or building new journeys such as the ones we saw at yesterday’s Keynote. I know that was a whirlwind. This presentation was built very to complement the Journey Builder for Apps book, which we’re giving away for free at the Dev Zone. Please feel free to drop by and pick up your copy. And with that, let’s open up the floor to questions:
• #37: Data Contract: URI HTTP Verbs, Response Codes Request Parameters Request / Response Body Definitions
• #38: Data Contract: URI HTTP Verbs, Response Codes Request Parameters Request / Response Body Definitions
• #39: Goals of the client libraries Write less code Make it possible to accomplish advanced use cases (the “20%”) Expose the same objects and properties… … but do so in a way that feels “native” to the language or environment being used Java, PHP, C# libraries officially supported Expect Feature Parity Across all Libraries Auto-generation based on our API Discovery Service
• #40: We’re currently developing an API Style Guide, which we will publish on Code@, to ensure Consistency across our RESTFul Interfaces Will define * common parameter names (e.g. created and modifiedDate), custom interactions (e.g. related object hydration, pagination, asynchronous activities) Goal : developers can predictably interact with the API with less frequent trips to the documentation