Web Analytics vs. Scrum/Agile

“Back” in the good old days of web analytics, where projects were based on deadlines and implementing web analytics used to be a straight forward process of ensuring that everything was up and running before the deadline, has the last couple of years been challenged by evolving methods in the project management field. So how should we as web analyst get our heads around project that are defined as Scrum or Agile software developement? To address this issue, we first need to understand what Agile software development is, Wikipedia gives the following short description of the methodology:

“It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.”

Even though many people do love this approach (which also makes sense from a development point of view), but from a web analytics point of view, it´s a nightmare. We can in the development process be forced to change our tracking framework several times if we use the traditional method of focusing solely on the wireframes that are initially built.

To ensure we don’t get frustrated and annoyed by the many changes, it is vital for the web analyst to have a meeting with the stakeholders of the project to ensure what the outcome of the delivery is, in other words, what are the business objectives. Once you know the over-all business objectives you can begin to have meetings with the UX team to better understand their approach for their framework and ensure that they have data to back up their hypothesis (You will be surprised to see how many people still build wire frames based on assumptions), ensuring this could potentially save you hours of work in the long run, because the arguments are based on data and not assumptions that can be pulled apart by any team member in later stages of the project.

Let’s quickly have a look at what we know so far from the project:

1. We know what the over-all business objectives are
2. We have a good understanding of how the UX team is going to approach this project and what they are planning on building

The third step is important because you will be walking into the deep of the abyss, straight in the dungeon of developers that are eating Scrum for breakfast and Agile for lunch. You need to understand which type of technology is being used and understand how your web analytics tool will work with the technology. To name a few examples, you could be working in AJAX/Single Page Applications, which more or less consists of one page load that is not plug and play as in traditional html pages that call the server for a new page load each and every single time a new page is served to the end-user. The same goes for apps, they can be tricky to tag, since you can have offline interactions with your app and you want to ensure your tracking request are as small as possible to give the end-user a good experience of your app. Both Google and Adobe have mobile SDKs that take that into consideration when building your analytics framework for mobile and apps.

Step 4 is to sit down and figure out what is the most basic information that you can build into your framework today and what can wait to the end of the project.

I always recommend to build a data layer framework no matter which tools you are using, even if you don’t have a tag management system. Why? Because you want your tracking to be tool agnostic and ensure that the custom data layer can be modified by any developer and not only by that one person, that was allocated to implement the tracking. Doing this will also ensure that you are building a future proof framework that will be easier to manage over the years and will work flawlessly with your third party tags as well, since you will be using the same data source to extract data from. In the ideal world, you would have a data layer and a tag management system where you can map your variables on your own.

If you are working in a team that is keen to do everything scrum/agile, you will discover that the look and feel of things will change, but the overall business objectives will be the same.
This is important to keep this in mind, since each development cycle in a scrum/agile methodology will have made changes to what you saw in the last sprint. So how do we cope with that, we need to implement tracking at one point and can’t do everything on the last week… can we?

First of all, focus on what is critical for your tracking.

This could be (not limited to):
– Pagename
– page type (FAQ, Product page etc.)
– Product name, details etc.
– Order confirmation page details (revenue, quantity, price, etc)

Some of these things will be mandatory in any tracking and it is best to have this in place in your framework from the start and have your developers deliver this as early as possible.

Example:

Let’s say you are working with a bank and they want to track how their online loan calculator is performing and stitch that data to any offline loans given made by filling out the contact form online.

In a traditional project, we would wait for the wire frames to be finished and most likely also wait for the project to close to finished, but luckily we don’t have to wait that long because we have done our homework pretty well.
Knowing that the business requirements are to collect data on what the amount requested for the loan was and connecting that information with the form being sent, we can easily build those requirements into the framework, since they are business related and purely focused on the outcome of the built functionality. Ensuring this early on in the project will make it easier for you to go along the agile development and be able to present reports based on the current build that the developers are working on. If you document everything based on the wire frames built in a Agile project environment, you might find yourself swearing multiple times during the project, because you need to redo your tracking. It is vital that you ensure the basic business objectives are tracked and data collection in place and wait for the very end of the project to get clarified what the project is going to release, for instance:

“How many steps are there in the loan calculator?”
Example: The project wire frames showed 4 steps but not we only have 3.

“Do we have a dynamic form that doesn’t reload after the loan calculation is successful?”
Example: That was the original plan, but we implemented a separate page with details so it was easier for the customer to see all the details in a print-friendly way.

The 2 examples above are things that is not vital for your succes, but still important enough for you to take those considerations into how you will collect data and build it into your framework.

My advice for people that are working with agile/scrum is to be patience. Implement the most important bits and plan for what is coming by joining the scrum meeting and have a say whenever some changes might have some implications on the data collection, because no one wants to build something that can’t be tracked and jeopardise the project. Remember, no business in the world would build something they can’t utilise.