Exploring Forms Tracking with Custom Data Types in Adobe Customer Journey Analytics
I can’t think of any analytics tool that got me quite as excited this year as Adobe’s Customer Journey Analytics, especially with the recent addition of Derived Fields. While there are some features still missing from Adobe Analytics, it should become more and more clear that CJA is already superior to the vast majority of the market.
While I’ve already done an extensive series of posts on how to get started with CJA for a website and exploring the mobile AEP SDK, the new tool brings up many, many questions around setup, admin, and implementation. While the interface for business users is the familiar Analysis Workspace-democratization-paradise, all of the new and shiny capabilities invite us to re-think how we provide analytics capabilities to our companies.
In this post, I want to take a look at an evergreen of digital analytics: Form tracking! Unperturbed by any recent trends, websites like to use forms to collect information from their customers, so we should have a good way of capturing it for analysis purposes. I admit, it’s not the most prestigious topic to pick, but it allows us to cover a much more exciting capability of CJA and AEP. With their re-usable, custom Data Types, Experience Platform gives us an amazing way to be both flexible and efficient with structuring data. So, let’s dive straight in!
Re-thinking Forms tracking
Before we even touch Experience Platform or Customer Journey Analytics, we should first think of what information we want to track. In the old Adobe Analytics-world, we would have to find a way to map information from a form to a flat list of props, eVars, or List Vars, while balancing re-usability and specificity to not waste too many dimensions.
Luckily, AEP and CJA allow us to think in multi dimensional objects, arrays, and lists! Also, since we are not limited by the risk of running out of dimensions or into high cardinality/Low Traffic problems, we could feasibly track all fields and submissions. So, with an open mind, let’s first think of what we are interested in.
To start with, I think tracking the name and type of a form would be a good base. The name could be uniquely set by page authors, while the form type allows us to differentiate sales forms, newsletter signups, and whatever your company might use. We then accompany this basic information with the simple number of sections (more on that in a second) in the form.
Many forms have something similar to sections. A section could be used to cover parts of a single-paged form (like a payment and address section) or even represent multiple pages of a larger form. A form might have only one section or many, each of which can then have one or more form fields. Those sections also should have a name, as well as the position or index of the section within the form. For convenience, we will also track the number of fields in each section.
On the third and last level, we finally track the individual form fields within a section. Each field again has a name, type (like a numeric or text field), the actual value, as well as the position within its section. An example of how we would track all of that could look like below, for John Doe of ACME corp filling out a product trial form:
{
"name": "Product trial access",
"type": "Sales",
"number of sections": "2",
"sections":[
{
"name": "Personal information",
"position": 1,
"number of fields": 2,
"fields":[
{
"name": "First name",
"type": "text",
"position": 1,
"value": "John"
},
{
"name": "Last name",
"type": "text",
"position": 2,
"value": "Doe"
}
]
},
{
"name": "Company information",
"position": 2,
"number of fields": 2,
"fields":[
{
"name": "Company name",
"type": "text",
"position": 1,
"value": "ACME corp"
},
{
"name": "Company size",
"type": "number",
"position": 2,
"value": "10000"
}
]
}
]
}As you can see, we are using AEP’s most powerful feature here: Arrays of objects, containing even further arrays of objects! Gone are the days where we would have to sacrifice many, many eVars to capture form information. This structure helps us to keep things abstract while also providing all the detailed information we need. Neat! Now, how do we set this up in AEP? I’m glad you asked!
Custom Data Types in Adobe Experience Platform
AEP requires us to use XDM Schemas to structure our data. And we could just use one big, custom Schema to define all the desired fields directly on the Schema we create. While that would work well enough if we just ever use that one Schema for all our Datasets, we would need to redefine all fields for every additional Schema! That’s not very efficient. But wait, what is this tantalizing menu option in AEP’s Schema management?
That’s right! Platform allows us to define our very own data structure in a composable, re-usable fashion! I’ve personally never used this option before, so why not give it a spin? Let’s start with a simple custom Data Type for our form fields:
Easy enough, right? As you can see, I define that a form field Data Type contains a name, type, value, and position to describe the field. Sounds simple. Now, you might be asking why this is worth the effort of using custom Data Types. Hopefully, this becomes a bit more clear when we start building another custom Data Type for our form sections:
As you can see, I’ve already added the name, position, and number of fields for this section. But now, instead of having to define all of the Form Field structure manually, I can just reference the freshly created Generic Form Field, as you can see in the red box above! Once we select that, AEP automatically pulls the definition of a Form Field into the Schema for us, so it looks like this:
How great is that! And if we ever need to update our tracking capabilities, we can just update any of those generic Data Types, which makes the update available wherever we used it! Now, we can also define the full Generic Form Data Type for the whole form tracking, composed of the existing smaller pieces:
Looking great! Now, the amazing workflow that this structure allows us to follow, is to simply update any of the atomic elements without the need to change them many times in many Schemas! To prove this, let’s change the Generic Form Field we just created. Maybe, we want to add a Numeric Value field and rename the existing field to “String Value”. We just have to do that once in the Generic Form Field type:
Once we hit save, we can now take a look at the Generic Form Data Type. And, sure enough, there are our updated fields, without any changes to the surrounding Data Type:
What a great success! This is much smarter than changing the same fields in many, many Schemas.
You may already ask yourself: Why didn’t we use a custom Field Group here? Are those not able to do the same thing? Not quite! While the custom Data Type allows us to use our custom data structure anywhere in the XDM Schema, a Field Group will always stay in the same “place” within the XDM hierarchy. While that can work for large, static data structures, our approach allows us to use the new Data Type anywhere in the Schema, even multiple times!
In this example, I simply extended the Web SDK Field Group with my new Data Type, giving me everything I need to start tracking form submissions:
How great is that! With this neat, little technique, we can save ourselves a lot of time and headache in the future. Of course, tracking forms is only one of the many applications for this feature. But before we wrap everything up, let’s take a quick look at our data in CJA!
And there we go! With just a couple of generic fields and custom Data Types, we are now able to track pretty much every type of form we could ever want. And thanks to the composable Schema principles in Experience Platform, we would always be able to add new capabilities to existing Schemas and implementations from a central place! Amazing! Now, it’s finally time for the…
Wrap up
This was a fun little experiment! Even going into this with zero experience in setting up custom Data Types in Experience Platform, we were able to create a couple of very flexible Data Types that will allow us to be super quick and efficient with future updates! Once we figure out a new, exciting new way to track forms, we can just roll it out across all of our implementations and Datasets. It’s truly amazing!
I hope this short post was able to demonstrate why my excitement about AEP and CJA is climbing to new heights with each release. And while there are many new concepts and features to explore and wrap our heads around, the new opportunities are already endless! Even if we just want to continue with a numbered list of dimensions and events, there would be nothing stopping us from shooting ourselves in the foot as often as we like! I’m personally not a fan of that, but the choice is truly yours!
Thank you for reading! check out the recommended articles below and enjoy the rest of your day!
German Analyst and Data Scientist working in and writing about (Web) Analytics and Online Marketing Tech.
2021 – current Adobe Analytics Champion
EMEA Adobe Analytics User Group Lead
Adobe Analytics Community Advisor