iPadOS in Digital Analytics workflows — can it work? Part 1 — Home office and digital analytics platforms

I’ve got a confession to make — I’ve always been a nerd and as one, I’ve always liked all kinds of tech gadgets available (if you don’t believe me, ask my wife. 😉) Because of that, for years now I’ve been looking for a tool different from the usual laptop or desktop that I could use on a daily basis at my work in the glorious field of digital analytics. Unfortunately, I have never been able to get there:

I tried a couple of Windows tablets starting as soon as Windows 8 came, but despite their advantage of compatibility with all the Windows tools, they have never been good tablets with the user experience becoming quite unpleasant quite quickly.

I tried switching at least part of my workflow to both Android and iOS smartphones and, even though they were quite close to making it work (especially with some Samsung phones making the process of Linux installation quite seamless), the limitations of a small screen kicked in quite early, resulting of me always switching to a latop as soon as I needed to do anything more serious.

Finally, with its great battery life and quite a bit of fun factor, I have always loved playing with iPads, so with Apple introducing more laptop-like features within iPadOS (and marketing it as a “real computer”) I decided to grab a new iPad Pro (although everything in this article would be applicable for any other iPad as well) and check if their claims also apply to my professional work. For people outside of our small niche I think it’s important to understand what does a day of a modern digital analyst look like. In my experience, it’s a mix of typical office work, project and product management, documentation writing, web development, using proprietary web-based platforms (and, often, browser extensions — spoiler alert, this will not end up well), data analytics (ranging from preparing Excel reports to running Spark clusters), data engineering and data visualization.

As you can see, it’s a combination of a few professional backgrounds and workflows, so to make the article as readable as possible, I decided to divide it into their respective sections. Also, to avoid it being too long, it’s split into two parts. In this one, we’ll focus on the usual office work and the “real digital analytics” — using tag managers, web analytics platforms, maintaining their setups, etc. In the second part, we’ll look into “real” data analytics, as well as data and app engineering we also sometimes have to take care of. If you have a particular topic or a tool you’d like me to check out, let me know — either using a comment section here or contacting me on the #measure Slack channel.

Getting around the (home) office

This was the part I was sure iPad is going to nail and I was not disappointed — it’s a great tool for answering e-mails and messages, managing your tasks and calendars, tracking your time, work on your documents or researching the web.

For e-mails, documents and cloud storage, I’m usually using a combination of Google and Microsoft accounts. As expected, both of them come with a suite of iPad-native apps and integrate nicely with iOS (eg. with the Files app), so I haven’t really missed anything there. I don’t think that the iOS’ Excel version support proper macros and VBA development, but neither does its macOS equivalent, so if you use them or eg. Power Tools, I think you’ll have to stick with Windows. Another consideration is that adding an Exchange or enterprise Office 365 account to your iOS device will grant the administrator (most likely your employer) access to eg. remotely wipe it whenever they please, so unless it is company-issued, I’d advice against doing so. As a workaround I’ve simply used Microsoft’s own Outlook app — when you set up your account there it can be wiped as well, but it’s limited only to the app itself and the rest of your phone or tablet will remain intact.

As for the rest of the tech stack commonly used by the companies to facilitate office work, I gladly report that in majority of cases it works like a dream and sometimes, the overall experience was better than using a regular laptop. Having tested Slack, Jira, Confluence, Notion, Toggl, Trello, Google Meet, Microsoft Teams and Zoom applications I have only stumbled upon a couple of minor issues, usually having to do with the company software not being up to date or with iPad’s implementation of multitasking, namely:

• For Jira and Confluence Server connection, the installation have to use a specific version — if it’s older then the apps won’t work and you’ll be stuck with clunky (and old) web apps,
• when on a video call with any of the apps, whenever you get out of its exclusive scope (eg. splitting a screen with another one or using these mini overlay apps) the video will be stopped (but audio will keep working.) I hope that Apple will fix it in the next update, as it seems like a weird oversight.

The only infamous example of an app that treats iPad users as second-class citizens is Slack that doesn’t support video calls on iPadOS / iOS at all. Shame on you, Slack! Nevertheless, besides that inconvenience, the experience was very fine — Notion’s great Apple Pencil support means you can write your documentation without a keyboard and I was pleasantly surprised that some video conferencing apps allow for iPad screen sharing. Who would’ve thought?

Working with digital analytics platforms — the good, the bad and the ugly

Time for Captain Obvious’ revelation — office work is fun and all, but digital analysts can’t work without their beautiful digital analytics platforms and tag managers! That’s why we’re here in the end, aren’t we? I haven’t forgotten it! For my tests, I have mostly focused on the solutions by Google, Adobe and Tealium, but the general conclusion is quite universal: most of web based applications work fine. If you therefore need to quickly change your custom dimensions setup in Google Analytics, modify the Adobe Analytics workspace your marketing department uses or adjust your Tealium Load Rules, you should be able to do it without any problem.

The only potential issues that I’ve found occur when a platform bases on a drag and drop interface or a view has multiple panes with separate scrolling. In some cases it works perfectly fine (I’ve got a feeling that our friends at Adobe took extra care about it with their interfaces — both Analytics and Launch are a bliss to use with a touchscreen), but in some others (<cough> Google… <cough>) the experience is quite clunky and requires multiple tries to work. It’s not a dealbreaker by any means, but with a high bar set by Adobe, it’s a pity that other vendors did not follow this example.

This brings us to the real stuff — tracking implementation within the web applications. First of all, before I forget, the new Google Tag Manager Preview mode is simply not working. New tab is never opening. I understand that it’s a limitation of mobile Safari / WebKit, but it’s a pity that GTM’s product team has not checked it before deciding on the new Preview mode implementation. Perhaps they could take a look at it now?

Moving on, no matter whether you use the browsers’ developer tools or a set of curated browser extensions, there are essentially three things we need to do in our work:

• verify (and modify) the browsers’ requests,
• access the HTML,
• access and debug the JS executed in the browser.

As this has always been a problem with any mobile OS in my past experience I was keen to find out whether it’s changed. Has it? Well, kinda…

With the mobile Safari’s lack of any developer tools, I started to look into alternatives and stumbled upon Inspect Browser. It basically provides a set of basic developer tools with a WebKit window and comes with HTML elements inspector, basic requests preview and JS console. For example, that’s what it looks like with _satellite.setDebug(true); enabled for Adobe Launch debugging:

As you can see, it’s quite comparable to what you’d expect from a regular, PC browser. It also enables you to preview your data layer contents and in my opinion is a real game changer for tracking implementation setup and debugging. The only downsides I’ve noticed so far are that it doesn’t provide a real JS debugger (so if you need one on a regular basis then you’ll need to either bring your laptop with you or look into a remote solution — we’ll discuss those in Part 2 of this article) and does not preview body of some types of the requests. If you’re checking a GET-based implementation, with all the data attached to the request as query string parameters (eg. for both GA and AA) it is not a problem at all, but with form type POSTs (as used by Tealium Collect) it is not really working.

Fortunately, it’s easily fixable using iOS version of my beloved Charles Proxy. In general, it behaves very similar to its macOS and Windows variations, displaying all the HTTP traffic there and enabling to decrypt SSL connections using a prepared certificate. It might not be the prettiest solution out there, but is surely something one can work with:

Unfortunately, this is basically the only feature of the mobile version and lacks all the request modification features of its big brother. For example, I always use the “Map Remote” feature to switch between different Tealium profiles and environments, but unfortunately I haven’t found a way to do it solely on an iPad yet.

In such edge cases one could use the connection through an external server, which might be a valid option if it’s not required on a regular basis. We’ll look into it in the next part, more heavily focusing on the engineering part of a digital analyst’s work! Stay tuned!