#007: How Can Analysts Effectively Build Out Their Technical Chops?

The following is a straight-up machine translation. It has not been human-reviewed or human-corrected. However, we did replace the original transcription, produced in 2017, with an updated one produced using OpenAI’s WhisperX in 2025, which, trust us, is much, much better than the original. Still, we apologize on behalf of the machines for any text that winds up being incorrect, nonsensical, or offensive. We have asked the machine to do better, but it simply responds with, “I’m sorry, Dave. I’m afraid I can’t do that.”

00:00:04.00 [Announcer]: Welcome to the Digital Analytics Power Hour. Three analytics pros and the occasional guest discussing digital analytics issues of the day. Find them on Facebook at facebook.com forward slash analytics hour. And now, the Digital Analytics Power Hour.

00:00:26.64 [Michael Helbling]: Hello and welcome to the Digital Analytics Power Hour. This is episode seven. How analysts can build out their technical skills? This episode is coming to us from some of our listeners. Drew Gettemiller and Cleve Young both suggested this topic after listening to some of our earlier podcasts. And we really thank you guys for the feedback and the opportunity to respond to kind of your questions. We also have a guest tonight, Jeff Chason. He’s a marketing cloud evangelist at Adobe. He’s been in the digital analytics space as an analyst for many years. We spent time at IBM and other companies. I think he brings a great perspective. And some of his recent writing is very much on point with this topic tonight. As always, we’re also joined by my co-hosts. We have Jim Cain, Master of the North in Ottawa. Hi, great title. Thanks. Hey, you know, I’m trying to mix it up a little. And of course, Tim Wilson, also a Master of Slightly Less North in Columbus, Ohio.

00:01:27.23 [Tim Wilson]: But still with a little bit of snow.

00:01:29.38 [Michael Helbling]: There you go. And I’m Michael Helbling, and I am not a Master of the North anymore. All right, so let’s get into this. There’s a lot of things that digital analysts can do to enhance their career and their skill set. And there comes a time when they really have to grapple with this concept of, do I need more technical skills, like if I come from a more pure marketing or business background, how much development of my technical skills should I try to pursue? What’s the right level? What kinds of technical skills? How deep should I go? What’s the benefit to your career? And so let’s dig into that. Tim, why don’t you kick us off and start with this concept of what skills out there should a marketing analyst or a digital analyst build and how competent should their technical skills get?

00:02:18.94 [Tim Wilson]: I think it can never be technical enough with the limitation that you don’t want to spend all your time just becoming more technical. But I kind of look back as we were sort of thinking and talking about doing this episode and look back over the last three months, six months, a year. I mean, I can trace my entire career and analytics back to specific points where I sat down with Somebody or did some digging somewhere or dug into some code somehow to get a better understanding of the technical and that’s a broad term to say that the technical side of web analytics. It’s it’s everything from. What I would consider the basics of what is the structure of a URL, how is the hostname different from the protocol, from the path, from the parameters to how does JavaScript work and actually capture data all the way to, you know, what is the DOM, you know, why when I view source on a On a web page, does that look different from if I look in the debugger tools? The code doesn’t match exactly, character by character, all the way through to sort of the back end of after we’ve captured the data, what’s happening with it? There’s a limitless amount of technical information to learn, and there’s not a single piece of that information that doesn’t hold you in good stead for one of at least two reasons. One, from working with developers, The more you can speak in their language, the more likely you are to get what you expect and quickly have a very strong and positive relationship with them and have them bending over backwards to do kind of unique data capture, but also when it comes to troubleshooting or when it comes to actually assessing a project and saying, what are our opportunities here? How could I kind of architect a solution to capture this data? And ultimately all the way through to how can I build a segment? It all is kind of this one continuum from how the internet works to what is the report that I’m presenting, that’s all just kind of bits and bytes flowing in different places. And every time a light bulb goes on for a new thing, I can tell that I’ve become a better analyst. So to me, it kind of runs the gamut. I can point to specific things that I am still weak on and try to get better at. And I can point to things that I’ve become pretty solid on. And to me, when I run into an analyst that wants to just live in Psycatalyst or Discover or Google Analytics and says, I don’t need to know any of that other stuff. I just want to crunch the data. They are by definition limiting their ability to be effective and productive. Now that we throw it to Jim to immediately say, that’s wrong.

00:05:00.68 [Jim Cain]: I’ll actually let Jeff go first before he goes. I want to say, Tim, you’re wrong. There.

00:05:08.03 [Jeff Chasin]: The big problem that I run into, and I’ve been thinking about recently, and I wrote about recently, and I’ll probably do some more writing in the near future, is that when you’re a web analyst, it’s a lot different than other types of data analyst positions. Analyzing web data is different from analyzing data out of CRM systems, or data out of point of sale systems. It’s different than just about any other type of data from the standpoint that it’s dirty. So whatever web analytics tool of choice you prefer to use, whether you do visualizations in Excel or you have some sort of visualization tool like Tableau, or you’re sitting in front of R all day long and you’re doing more statistical types of analysis, my belief is that the more that you know about how, when, and where your source data was collected and the technical things that impact that data, the more you know about that, I think the more effective you you have the potential to be more effective and to do better analysis.

00:06:07.37 [Tim Wilson]: Is that because you’re avoiding pitfalls or because you’re being able to more quickly get to what you’re looking for?

00:06:14.19 [Jeff Chasin]: A little bit of both, I think. There’s tons of pitfalls, even analysts that aren’t implementation specialists that are just straight up business do business analysis and they present to marketers and executives purely from a business standpoint and not a technical standpoint. If something’s totally jacked up across an entire website or across a site section or across a particular landing page from a technical perspective, that impacts their analysis and they need to be aware of that because it can dramatically affect the quality of the data that they’re using in their reports and in their analysis. So something’s implemented incorrectly. Something is implemented twice on a page. There’s a redesign for a site section. Say you’re in e-commerce and you’re in a retail situation where some customers come in the store, they’re adding things to the cart, and maybe they bail out in certain product categories. Or there’s a spike in the number of customers that come and add to cart that don’t complete their purchase. So you have an increase in fallout, and you try to investigate those patterns.

00:07:22.08 [Tim Wilson]: Well, I will say, I do think data in other CRM systems, and I mean, I’ve worked in my BI days. The CRM especially in call center data is often, I think every analyst actually kind of assumes their data is cleaner than, or their data is dirtier than other data. So I would, I agree with everything you said, except for the fact that the digital analysts are particularly unique. I mean, I think it’s unique maybe in that we’re dealing with more dynamic systems and processes and that you know a new chat feature gets rolled on the website whereas a lot of times your transactional systems are a little bit more stable from the data capture but you know the classic call center of somebody’s thrown in a drop-down box because they want to figure out where did you hear about us and shockingly the top item in the drop-down box is what gets reported for eighty percent of the customer records because the call center reps are are selecting are just getting past the field i think that that goes to almost any kind of analyst that’s dealing with volume data that’s being collected through processes that they can’t super, super, super tightly control. There’s a need to understand really where is that data coming from.

00:08:38.53 [Jeff Chasin]: And I run into just sort of as some context, what I run into very often, commonly with people that are in marketing, digital marketers, merchandisers, people responsible for promotions and campaigns and also with analysts, is just at a very basic level, you get on a conference call and you’re talking about a new initiative or you’re talking about Some new tracking or new piece of the website new content on the websites is being added or new campaign or new product category something’s changing or being added to the site you want to add tracking want to do analysis. You want to make sure you’re collecting the right data there are terms that are thrown around on these conference calls that if you ask 10 people after the call what. was discussed, you’ll have 10 very, very different versions. And a lot of that is caused by, I won’t say the misuse, but a misunderstanding of some of the technical concepts. The other aspect that comes into play is that websites at large companies are becoming a lot more like a collection of web applications. So implementing analytics and being a web analyst responsible, working with data that comes out of a site that’s mostly based on content, like a media site, A blog, even if it’s a corporate blog, versus an e-commerce site where you have a lot of Ajax running on the page and you have quick views and overlays and modals and you can do things with that content.

00:09:57.69 [Tim Wilson]: Ajax, you mean people are cleaning their screens while they’re viewing the website? Is that what you’re referring to?

00:10:03.66 [Jeff Chasin]: I think scrubbing bubbles are important for a website. That extra scrubbing power so yes that’s a great example right Ajax is a term that gets thrown around just about every conference call them on people talk about synchronous code that loads or asynchronous code that loads and there are a lot of people on these calls that just stay silent because. they don’t think they need to care how that impacts the data that they work with or how they think they don’t need to care because they say something like, oh, I’m non-technical. I don’t have to worry about that. We have people that deal with that. And maybe that’s true, and that’s a great luxury to just deal with the business side. But I think it’s important for everybody that’s involved in promoting a website, especially when you deal with a large company, you have a ton of money. You have six, seven, eight, 10 figure sums of money that are going into these projects, I think it’s important that people understand just some of the basics about what they’re dealing with and how that can impact their data and impact their campaigns and their investments.

00:11:03.87 [Tim Wilson]: I always say it’s important that we need to call out the FUD and confusion on those conference calls so that everyone actually understands those TLAs. That’s just something I say a lot. Or maybe I read it in one of your blog posts. I could not agree more. I was actually on a call today where somebody used an acronym and I said, just hold on, what are we talking about? And I knew that three quarters of the people on the call had no idea. I didn’t know what it was. So I’m like, I’m pretty sure I’m not. I’ll ask the stupid question. And if I look stupid, that’s fine. But hey, it turns out that that was somebody who was deep in the weeds, was using their internal terminology. And it was kind of important that we understood what they were talking about.

00:11:43.34 [Jeff Chasin]: The other place that pops up a lot is when you’re dealing with a vendor, and I’ll be the first one to put the, you know, I know it’s the elephant in the room, but when you’re looking at a new piece of technology, new system, new tool, very often you have salespeople with a variety of levels of technical expertise or technical experience, and terms get used, and everybody assumes that everyone knows what everyone else is saying specifically, and a lot of times they don’t. And I think it’s just helpful for people to have a good grounding in some of the basic technical concepts.

00:12:13.03 [Jim Cain]: So I’m going to save my opening remarks and just mash them up with my closing remarks, because we’re about halfway through. Tim Wilson. You know what? This one was interesting, because I remember when we had the big data conversation, and we all ended up violently agreeing in the show notes and the planning and all this stuff. I really got a vibe from yourself and Michael that you thought today might be another. It’s a great topic. Listener solicited. Super cool. Obviously, we’re all going to agree again. And in this case, I really don’t. I don’t think that the name of today’s topic is how analysts can build out their technical chops. And I would say don’t do that. There’s a lot of other things that you could be focusing your effort on as far as career development is concerned than by parking your ass in the server room, getting in people’s ways, and not focusing on business value. Now, the thing that both you and Jeff said that I totally, totally agree with, you can’t sit at your desk and wait for someone to bring you perfect data or there’s a tool you log into that’s crystal clear and everything works and you need to understand how your food is grown before you can start to go out and cook with it and I totally understand that. But there’s a huge difference between understanding architecture and knowing how to drive a bulldozer. And I think that a good business analyst really understands all the pieces of the tools, how they work, how they should work. But if one of my guys came and said, I’m going to learn JavaScript, I would say, how about we don’t waste our time on that?

00:13:39.66 [Michael Helbling]: So maybe there’s an interesting dividing line here that is, as an analyst, you shouldn’t try to become a developer, a programmer, but where is that fine line? How much time should you spend developing a skill set? Here’s the other thing that I’ll challenge a little bit, Jim, is I think we all agree to be a good analyst. You’re going to need some data manipulation skills, whether that be inside of Excel or a SQL database or Tableau or any of those kinds of things. Those skills are technical skills as well. They require logic. They require manipulating software and those kinds of things. in terms of a website and how it operates, knowing how the bread gets baked and making a digital loaf of bread. My analogy is not working. You get what I’m saying though, right?

00:14:32.57 [Tim Wilson]: I think you’re actually getting to, there’s sort of two, I’ve been told that conceptually VBA and Macros and Excel and JavaScript are kind of kissing cousins. So there’s a level of I can make Excel more efficient and you can have a whole other debate around is should you be in Excel or not. I think the architect driving a bulldozer or hanging drywall is kind of an interesting way to look at it and maybe partly because I have a degree in architecture. At the time I got pretty geeked out about learning about how do buildings really go together. What the drywall attaches to the studs and the studs are 16 inches on center And this is kind of how things go together. That’s kind of an interesting analogy of at the same time, I’m not going to be the guy to come and float the drywall in your living room. It’s going to take me frickin forever. I can do it, but wind up with a hole in your wall and it needs to be patched. I know what I need to get and are the right tools for the job. And I can do it really slowly and really laboriously, but I know what needs to happen. And I know I can kind of marvel when I watch a painter or a drywall guy come in and kind of blow through that. So I think I kind of like that analogy of how much does the architect need to actually kind of understand the pieces and parts of how the building goes together relative to do they need to be the ones who can come in and frame a wall. And I’m not sure exactly where that’s going. The more that I can come in as an architect and talk to carpenter, talk to a concrete guy and really know what the steps they have to go through, the more they’re going to be receptive to what I’m doing and the less likely I am to do something wacky that is just a royal pain in the ass for them when I could have made it actually a lot easier on them to build a building.

00:16:31.01 [Michael Helbling]: I would definitively say that I have never been sad to have a technical skill, but I’ve often been sad not to have more technical skills as a digital analyst.

00:16:42.71 [Tim Wilson]: There’s my little anecdote of when Helbling, before he headed to the Deep South, was over at my office. This is my home office at the time. But he was giving me a product currently known as DTM and formerly known as Satellite Demo. And he was kind of bouncing around showing how you could kind of grab stuff. out of the dumb and I wasn’t quite keeping up and that was, I don’t know, was that a couple years ago?

00:17:09.60 [Michael Helbling]: Yeah, well over two years.

00:17:11.40 [Tim Wilson]: Well over two years ago and I feel like now, if you gave me that same demo, I would totally be following along because I was really just getting a handle on And for lots and lots of reasons, because that’s even helped me with, optimistically, and helped me with other, using other tools that are kind of that same sort of concept. And I think that’s made me a better analyst. But I don’t know if Jim’s still thinking.

00:17:37.26 [Jim Cain]: No, I mean, and I like the fact that you picked out tag management as an example of one of those dividing line tools and measurement, because when I look at a great web analyst, they cannot go into, you know, a DTM or in Sighton or Tilem or what have you and start writing scripts. They should not know how to do that, but they should be able to clearly define what should be measured, how it should be measured and manage the project between marketing IT. So requirements solicitation for marketing and IT kind of service management in terms of getting things done and into production.

00:18:06.35 [Tim Wilson]: But that’s fantastic, but what if actually it’s a really simple little technical thing, and I mean, Insight is a great example. I mean, I’m better at Insight than by far than I am in GTM or GTM, but it is actually kind of cool. I’m not going to go and say, oh, here’s this crazy, we screwed up on what we deployed, and now we got to kind of hack something to try to capture a piece of data, but hey, we just forgot to spec this thing, and it would be fantastic if I could start capturing it right now. It’s great if I can go into Insight and actually set that up. And I say that because I have one kind of active that that’s where I’ve done that. Or the flip side of, hey, I’d really love to capture. This is where I can’t do it. I’d really love to capture. I just got an error when I was submitting this form and realized we are not tracking how often that error is occurring. And I know enough technically to know that I’ve actually gone and inspected the element. So now I can make the request to my technical guy And say this will be really useful because I suspect this is happening a lot and I don’t know what’s causing it can you go into in this case in sight and figure out a way to scrape the down and actually capture and throw this into an event and I don’t think I would have known how to make the request in a way. That the developer in this case would have quickly said, yes, I understand the request and I can now run with it. So that was kind of the handoff. I wouldn’t have been a bad thing if I as an analyst could say, I need to capture this data. I only needed to capture four days worth of data. in order to go in to go to the client. So I actually went to my developer and said, I have a meeting next Thursday. This was like a Wednesday the week before. I was like, if we can get this in in the next two or three days, I am confident I will have enough data to actually go to them and say you have a legitimate problem. And I look at other analysts that I’ve worked with that aren’t trying to, you’re not as hungry for the being technical, and they just would kind of say, I’d like to capture that, and they’d sort of throw it over the wall, and they wouldn’t know, they wouldn’t be throwing it over with any sort of authority of, I know this is something we can detect. It was 10 minutes on my part to say, Inspective element in Chrome a couple of times and I can write up a set of requirements that I am pretty confident. The developer will say, yeah, I get what we need. I don’t need to iterate three times, three or four times and answer the question. I know what we’re trying to do. I can make that happen.

00:20:32.07 [Jim Cain]: When I look at the same process, I mean, what you just said was, I’m an architect and the building is a little bit behind. So I said, screw it. Give me a steamroller. I’ll help. Is it convenient to know how to do that? Yes. In my opinion, is it a big part of the reason why marketing departments and IT departments still don’t get along? Because there’s all kinds of people who know how to do a couple of technical things who are kind of getting in the mix. I think it’s a process management, a people management, a program management issue. I need to learn how to do everything. And Jeff,

00:21:00.94 [Michael Helbling]: Yeah, I’m pretty sure that’s not my IT and marketing don’t get along though.

00:21:06.48 [Jeff Chasin]: I agree with Jim in that as the architect, you don’t want to knock the guy driving the bulldozer out of his chair and say, let me take over. But your example of the people in the process, if you start asking for root causes of some of these issues, and I don’t like to say that they don’t get along, but they certainly could cooperate and communicate, which I think is the heart of the matter, better. So they’re talking about technical things. You’re talking about tags, you’re talking about pages, you’re talking about site performance, page performance, page load times, tag timeouts. Is our conversion pixel firing? Is it not firing? And maybe, you know, tag management obviously isn’t everything, and if somebody who’s Day in day out web analyst data analyst comes to you like you said and says should i learn javascript in your particular team that’s not really worthwhile but if that same person can’t open the console in the developer tools in chrome or in firefox or they can’t go into firebug and they can’t just at a very basic level understand what’s happening. They don’t need to write a whole JavaScript application, but the more they understand about what’s going on, the more they understand the base-level technologies that the web uses, all these new HTML APIs that are in play, pages are getting more complicated, sites are getting more complicated. And I just think at a very basic level, it’s advantageous for analysts to learn more about that environment that they’re working in, which is where their data comes from.

00:22:29.67 [Tim Wilson]: So that’s the good, so Jim, do you, so outside of learning JavaScript, would you, that’s a, I think that’s a fantastic question. I’ve worked with analysts who are not, they have no tool, not Charles Fiddler, the most have the Audenture Debugger, but it’s not, that’s sort of has its limitations, but do you expect that an analyst should be able to say, I’m going to go to the site, I’m going to click on this button and I’m going to be able to articulate what data is getting passed to the backend system?

00:22:59.07 [Jim Cain]: I’m thinking it’s a good question. I’ll give you a two-part answer. The first one is that all of my analysts should know what happens when a page loads on one of their stakeholder websites, whether it’s clicking on a button or whether it’s custom eventing or what have you.

00:23:12.24 [Tim Wilson]: Do they know that because they said this is what should happen or do they know that because they’ve gone and verified that’s what’s happening?

00:23:17.33 [Jim Cain]: Both. But the second part of my – so again, and that’s an example of understanding how your food is grown. A piece of that doesn’t work. They’re not going to be able to debug it. They’re going to be able to say, this thing that should look like this does not, and now I’m going to expedite a ticket to the department that fixes things that are broken. And be clear with them about this, because one of the problems with analysts that don’t know technology, is they just kind of you’ll fix it and flap their hands around. And I’m talking like a clear description of problem and requirement for resolution. So the other part of my answer is I could not open up the view source and tell you anything about what was going on with how measurement tools were deployed. I couldn’t debug that.

00:23:59.04 [Tim Wilson]: I mean, I think I’m with you. I mean, I’m with you on the, I mean, that’s, I put that on the I kind of actually do think I keep wanting to go take a Code Academy course on JavaScript or something, but I actually have worked with analysts who, you know, they’ll say, how do I set up this goal or how do I pull this data? And I’m like, the number of times that I get asked to pull something and the very first thing I do, I don’t go ask for the tagging document. I go through the experience. I pull out my notepad and I sit there and sort of take notes of I went through this experience. and I’m watching what data is getting fired off to the tool, which means that, and sometimes I’m using Charles because it’s much of on click stuff for Adobe, I’m like, I want to see what EVAR 5 is getting populated with when I do this, and then when I do this, and then when I do this. And I’ve worked with analysts who, they don’t really even see that as their role to be able to do that, and it sounds like you’re saying, yeah, That’s not cool. Like you’ve got it, which means that you need to understand kind of fundamentally how the data gets captured. Not how the code is written, but you can go to a developer and say, when I click on this button, this is supposed to happen. And not necessarily say, I’ve gone and debug your JavaScript. I’ve gone in and looked at your code and said, why it’s not happening. It sounds like we’re in violent agreement on that. Yeah, absolutely. If you’re an analyst and you are not, you don’t have a go-to debugging process, you’re not able to actually QA the tagging you provided, that’s a problem. And then there’s a lot more of a debate of should you be able to go in and look at the code and say, this is why I think it’s wrong. And that’s where you’re feeling like there’s

00:25:36.92 [Jim Cain]: That’s why there’s an IT department. Now, if we were to wrap this up into a takeaway, so I’m an analyst, I want to develop my technical chops. We’ve now clearly defined that there’s something there. You have to understand all aspects of a digital analytics deployment, like what they do.

00:25:52.37 [Michael Helbling]: Well, here’s the thing. I think we’re coming to a little bit of alignment on some level of technical understanding of how digital analytics transpires. We may have still some varying degrees of disagreement around sort of how deep an analyst should go or not go. What I’d like to do is actually spend just a couple minutes getting some ideas for that analyst who wants to make sure that they’ve got the rounded corner on how do I add just these things to my tool set so that I can be that guy who understands how the sausage is being made. I may not be out there raising the sheep and then taking them to the butcher and all that, but I want to get a better understanding. So where do we send those people? What things should they do to get a little better at that? I’ll throw that back out there to the team. Let’s do a round on that and then we can do a little wrap up.

00:26:44.11 [Tim Wilson]: I’ll hit it first quick because I think it is absolutely its people. So I will rattle off these random names. I’ll say there’s a guy named Ernest Bueller. Lives in Austin and a guy named Ryan Rutan. There’s a guy Uh, dame kevin wall leidner who I work with now. There’s josh west who I work with now to me. The most I’ve, I have seldom, there’s actually a guy named Alex Smith that I worked with at resource. So I can name the developers who I have gone to and said, Help me understand how this works, not because I want to do your job, because I’ve realized that what I’m asking you to do, I don’t really understand what I’m asking you to do. And that’s not from a writing code perspective. It’s, I don’t actually understand the mechanics. A fairly recent example was actually getting Kevin Walleitner, who’s, I mean, he’s at Web Analyst Mystified, to kind of pull up and say, yeah, this is kind of how you can This is how you can manipulate the DOM just in your local environment. Here’s how you can learn how to play around with these things. So to me, the number one thing is figuring out who the very technical people are who are willing to spend some time. And this isn’t a four-hour course. This is, who can I periodically have them fire up a whiteboard? I don’t know how you do that. So I don’t think it is necessarily going and taking deep classes. It’s just saying that the architect analogy, which I’ll keep going back to, and I’m not going to use all the time. Do I really understand how that window keeps water from getting out? I don’t want to go and build the flashing, but I actually want to understand how the window keeps water from getting out. Who can I ask? Who can explain that to me? That’s kind of my number one thing is there are lots of developers out there who will happily spend time explaining that sort of thing to you.

00:28:43.31 [Michael Helbling]: What about you, Jeff? What kinds of tips or takeaways would you say to an analyst who’s looking to kind of develop a skill set to be more effective on the technical side?

00:28:52.48 [Jeff Chasin]: Well, I think anybody that works on the web, whether you’re an analyst or market or merchandise or whatever it says in your business card or your LinkedIn profile, if you work on the web or you work with the web every day, I think there’s a couple of Really basic, very helpful resources that I’ve used before. One is webplatform.org. They have some docs there. It’s webplatform.org is the URL. It’s a work in progress, but there’s some really good general web concepts and beginners guide material there for anybody regardless of your technical background or If you consider yourself completely non-technical, it’s very approachable material, starts at a very basic level, really easy to read one or two articles and pick up very useful information. The other one is mozilla.org. It’s actually developer.mozilla.org is where most of their documents are, the Moezilla Developer Network. Great to bookmark, and if you hear something on a conference call, you want to demystify some fear, uncertainty, and doubt, you want to clarify a term. great to jump in there and look something up and just get a quick definition or a quick example to look at to make sure you understand what’s being discussed or what you’re dealing with. The other one which I don’t hear very much in the analysts community, I don’t hear about it too much at conferences, but I think there’s a book called Landing Page Optimization by Tim Ash and I think the first four or five chapters of that book while they’re I wouldn’t really call them very technical. Probably the best grounding and introduction into basic digital marketing concepts that any analyst could get. Really easy to read, really approachable. You could read it in a weekend. It covers a lot of the basic concepts that I run into people that there’s a lot of confusion. So those are my three, and then I would echo what Tim said. I think people are the best resource. If you have a friend, a developer, You have a friend is a little bit quote-unquote more technical buy my coffee take him to lunch ask him the questions nice Thank you.

00:30:50.17 [Michael Helbling]: All right, so let’s do wrap this up and let’s put a bow on this Where do we land and what was a key takeaway for each of us? I mean let’s start. Let’s ask.

00:30:59.23 [Jim Cain]: Let’s start with no, maybe No, Tim. No damn it. I’m starting Tim So, you know, the things that kind of hurt.

00:31:09.34 [Tim Wilson]: Ignorant fucking slut. Sorry. I don’t think we actually admitted the explicit tag qualification, so that was gratuitous explicit language. Carry on. Carry on, fine, sir.

00:31:22.28 [Jim Cain]: My Canadian sensibilities are very offended right now. The things from my notes that really jumped out was the first one. Sometimes we have been equating being a power user of a tool with being technically skilled. So I’m great at Excel or Tableau or even Google or Adobe. That makes me technical. That’s an interesting separate discussion. I also think that we all agree that understanding how your data comes to you is critical. But I think that if you’re trying to look at developing your career, the ultimate goal is to be the go-to person in the organization to have questions answered that helps drive the business forward. The guy who can debug JavaScript is not that guy. And so if you have to pick a direction to go, understanding the business, understanding requirements, solicitation, project management, the high level how the business moves with data, I would spend my time there every single time and ask IT to fix stuff when it busts. That’s my wrap up.

00:32:17.11 [Michael Helbling]: All right. What about you, Jeff?

00:32:18.88 [Jeff Chasin]: I think you can, as an analyst, I would partially agree with Jim that certainly you can add more value in terms of increasing revenue or decreasing costs or increasing customer satisfaction on the business side. It’s a lot more challenging to do those things purely from a technical perspective, but just my sort of motivation for asking people to be a little bit more students of the game, so to speak, is just that because we deal with technical things, like Jim said, whether you’re a power user of a tool and you’re very good at using the tools that you use every day, or you’re somebody who understands how to pop open a console and understand the difference between a severe JavaScript error and one that’s not such a big deal, I think the more we can learn about the technologies that we work with, the better off we are and the more value we can contribute to the organizations we work in.

00:33:05.71 [Tim Wilson]: I’ll dive in. I’ve blathered throughout this, so I will try to be brief. One takeaway is maybe I am just a want-to-be developer who can’t quite get there, because I still get I really enjoy when I get to dig in for a few hours and get smarter on the technical. And then I feel like I’m using that for years and years afterwards. I think the talking to people, I made notes about some of Jeff, the web platform.org and developer.mozilla.org. I’m actually not familiar with one of those. So I’m going to be checking both of those out. I have jumped into, I’ve taken Coursera courses. I have not done anything on Code Academy, but I’ve thought about it. If there’s that takeaway, I do encourage people for a relatively brief post and I just gave it a try. I’m pretty sure here’s your long tail search of the day is, are you a student of the game analytics? I think Jeff’s post, which was very, very concise. And I mean, anytime you’ve got a big nice, nice Hawk and David Foster Wallace, may he rest in peace. quote, you’re in for a winner. So it makes the case pretty well there. The one thing I do think we didn’t really talk about, and I was realizing that Cleve Young being one of the people who recommended this post, there is a role. And I think this role is growing in the analytics world of where you’ve got analysts who are doing analysis, and then you have analysts who are kind of implementation specialists or operational implementation people. And even in the show prep for this, Jim, my erstwhile nemesis, I think, had even referred to a role that’s kind of bridging between a missing role in most IT marketing or charts around technical operations that If you’re in an organization where you have the luxury of having someone who is in that role that is fantastic. There is a huge watch job opportunities come up that are people who are that are companies looking for Adobe analytics implementation type type people and those are people who specifically. Can kind of bridge between it and I would say more often than not the analyst and also organization but if you’ve got one of those people and have I’m lucky to have a couple of clients that have people who do that they’re also a fantastic resource because they really are. They’re responsible not for doing analysis, but for making sure the data is coming in and understanding the mechanics of how that data is flowing. And I will still land on, I think, the analysts need to be understanding that as much as they possibly can, understanding the architecture of it. So I have seven takeaways for me from this discussion.

00:35:45.58 [Michael Helbling]: So I think for me, a couple takeaways. One is if we were in different careers, I would be a chef and Tim would be a carpenter. And it’s in our analogy usage this evening. You know, throwing way back 2004, 2005, Eric Peterson in his presentations and speaking, would throw up a slide that had this hybrid analyst. And it was this dual capability person who had both technical as well as analytical skills. So even that long ago, this debate or this concept was there. I’ve come to see analysts exist on a spectrum towards a more functional or marketing analyst toward technical. But I’ve never, ever encouraged people to steer away from the technical. I’ve never explicitly told people, hey, spend time becoming more technical. If you’re an analyst, you’ll never regret having more technical skills. And there’s a balancing act, and I think we talked about that a little bit too. I like that as well. It sort of don’t develop your technical skills to the disadvantage of your other analyst skills. Being technical and being an analyst, I think, are two things that go very well together in my experience. All right. Well, what an interesting show. Good topic for us to discuss. Thanks again to Cleve Young and Drew Getemiller for giving us the idea behind that and asking those questions about it. Very special thank you to Jeff. Thank you for being on and kind of giving us your point of view. I think it’s timely and we’re really glad to have you.

00:37:17.21 [Tim Wilson]: Can I throw in that I know that when this actually goes live that Mr. Kane and I will both be sitting at a lobby bar at E-metrics and biving and doing some unrecorded podcast work. So for anyone who’s listening who has, you know, pre the E-metrics keynote on March 31st is listening to the podcast, please do seek us out. Let us know what you think. Tell us where Jim is completely wrong. We’d love to hear from you.

00:37:48.86 [Michael Helbling]: All right. Well, that wraps our show. So we’d love to hear from you. What’s great about this podcast for us is the opportunity we get to interact with people in the digital analyst community. So if you have a question or you have a topic or something you want us to talk about, please drop us a line via our Facebook. which is facebook.com slash analytics hour. And you can also hit us up on Twitter at analytics hour. Thanks again for Jeff, Tim and Jim. I’m Michael Helbling. Thanks for listening.

00:38:24.27 [Announcer]: Thanks for listening and don’t forget to join the conversation on Facebook or Twitter. We welcome your comments and questions. Facebook.com forward slash analytics hour or at analytics hour on Twitter. So smart guys wanted to fit in. So they made up a term called analytics. Analytics don’t work.

Podcast: Download | Embed

Subscribe: RSS