We mixed things up a bit for our September event, both with location and format. Given the topic, we hosted the event at Denison Edge, which is a really cool venue!

The topic was inspired by the experiences of a rising senior at Kenyon College that, despite excellent qualifications and impeccable due diligence, barely managed to land an analytics internship in the summer of 2024. Some relevant details of that internship:

• The company that hired him was a small agency that had not really thought about having an intern
• Through a string of improbable but fortunate events, they hired him for the summer
• The student had a great experience, and the agency found that he added real value to their work
• Things went so well that the company kept him on for ~10 hours/week once he returned to school in the fall

That’s the happiest of endings, sure, but the CbusDAW organizers were struck that it was almost certain that this specific tale represented countless simlar stories that never came to pass. And that’s a miss.

Consider:

• Companies of all sizes (including small ones!) have data at their disposal that is underutilized due to a lack of resources
• College students today—across all types of programs—are developing valuable skills in programming, statistics, and analytics in the classroom
• Academic programs recognize the importance of their students getting hands-on, real-world experience, and there are any number of resources in place to support getting them that experience

We brought together four panelists from central Ohio-based higher education to have a discussion about getting all of those factors to work together to create more win-win situations. The panelists:

Matt Miller Denison University	Nimet Alpay Franklin University
Tom Metzger The Ohio State University	Kristen Astorian Ohio Wesleyan University

While the initial idea for the panel was “internships,” the panelists made it clear that internships are simply one way for students to get real-world experience while delivering value to organizations. Many data and analytics programs—both undergraduate and graduate level—require a capstone project that works with an organization and their data to deliver value (and capstone projects have the benefit of having instructor oversight and coaching).

Some keys to making an internship successful:

• The project should be meaningful—using interns to work on projects that are menial doesn’t benefit the intern or the organization that hired them
• The project should be manageable—dropping an intern into a monstrously complex data environment with overly ambitious ideas for what they will be able to deliver in a finite period of time is setting them up for failure
• The intern should have a primary point of contact for oversight—this should be someone who actually wants to take on the work. They’re playing the role of a guide, mentor, and manager all at once.
• Consider pairing the intern with someone deeply knowledgeable of the data itself—it can take months to ramp up on the intricacies of many organizations data environments. While students do need to get exposure to the messiness of real-world data and the often-daunting level of effort to “clean it up” as part of a project, it can be useful to have someone who knows the ins and outs of the various tables assist them in getting queries written.

There are also a surprising number of programs (if only the moderator of the panel was not also the author of this post—something of a hindrance to note-taking!) that provide support to companies who are open to taking on interns (or to working with students on capstone or other projects):

• The career centers at most universities have staff who are deeply familiar both with there students and what it takes to scope work and provide support in order to make student work productive and impactful
• Through various programs (a range of funding sources), companies can actually have interns’ pay subsidized (partly or fully)! The career centers at any school can point interested companies to resources for that.

It was very clear that, once an organization tries out tapping into student talent, they consistently extend and expand their programs over time. Have you given that a thought? Reach out to one or more of the people above to find out more!

For this month’s event, Matt Gershoff, CEO of Conductrics, traveled from the land of triple-digit heat on the regular (Austin) to the land of pleasant-temps-even-in-August (Columbus) to share some thoughts and examples about being intentional when it comes to data collection. If you attended the meetup, then you’re here because we promised that we’d post some useful supplemental information, and we’re going to flip the script of a normal recap post by putting those up front:

• [20-Minute Video] Matt’s talk at PEPR ’24—a Venn diagram with the talk he gave at DAW has something like a 63% overlap, although his DAW talk is a larger circle, as there was additional material! But, since we don’t record DAW talks, the PEPR talk is a good one to share with a colleague who is kicking themselves for not attending DAW.
• [<2-Minute Video] Matt talking about intentionality—not even remotely by design, this was a piece of an interview that another one of the DAW sponsors, Piwik PRO, did with Matt. Useful and thoughtful stuff.
• [5-Page PDF] Privacy by Design: The 7 Foundational Principles—a very worthwhile read; Matt focused primarily on Principle #2, but you’ll never believe what Principle #4 and #7 are! (Seriously, if you give it a real read, it will blow your mind a little bit; it’s almost three decades old and was an underpinning of GDPR!)
• Matt will also be on an upcoming (as of this writing) episode of the Analytics Power Hour podcast, so, if “audio only” is your or a colleague’s jam, smash the subscribe button there.

Matt’s presentation—with annotations added to make it an upgrade from “just the slides”—is included at the end of this post, but a few of the highlights from his presentation were:

• “Just Enough” vs. “Just in Case” Data Collection—Matt made a stronnnnnng case that the industry bias is for the latter, while “privacy by default” demands the former. “Just Enough” data means aligning to a specific and explicit task or objective and then collecting as little data as needed to complete the task. “Just in Case” is a “maximize optionality” play—hoovering up as much data as possible at as granular a level as possible so that there are as many possible “options” for doing “stuff” with it in the future. We are so wired to the latter that it’s uncomfortable to recognize why that Is. Not. Good.
• This doesn’t mean there are no cases where high granularity / high cardinality data is warranted—throughout the talk, Matt was clear that he was not speaking in any absolutes (unless we count as an absolute that, “all data collection should be performed with intentionality”).
• Many types of A/B tests, both univariate and multivariate, can be statistically evaluated without recording data at the individual user level—if you’re like the author of this recap, you’ve always operated under the assumption that A/B tests require capturing each user’s session, including which variant they were assigned to, maybe some other meta data about them (what level of a loyalty program they belong to, for instance, for “deeper dive analysis”), whether or not they converted, and maybe the amount of their purchase. 10,000 visitors in the test? That’s 10,000 rows of data! What Matt demonstrated was, um, no. That’s incorrect thinking. By using equivalence classes, some understanding of the maths underlying the statistical tests of interest (t-test, OLS regression, and more), it’s possible to simply capture/increment aggregated counts (visitor count, sum of sales, sum of the squares of sales) and perform the exact same statistical tests in a way that is: computationally less intensive, data storage much less intensive, and aligned with privacy by design principle #2: privacy by default (and privacy by design principles #3 and #4 and #7). Matt outlined a lot of this in this blog post (although he has since extended his research and thinking on the subject… and it continues to hold up!)
• There are different techniques and concepts that are good to be familiar with when embracing privacy by design—K-anonymity, differential privacy, global vs. local privacy, and more! The key with all of them is that they’re best employed when approaching them as privacy by design rather than privacy-tacked-on-later-to-maintain-regulatory-compliance.

A lot of ground was covered with pretty lively audience engagement and more than a few laughs!

The annotated slides:

And, as always, a few pictures to capture the atmosphere:

At our May 2024 event, Nick Woo from AlignAI shared a thoughtful and pragmatic perspective about how to approach figuring out what use cases are (and are not!) appropriate for AI. The turnout for the meetup was strong, and the discussion was lively!

Nick started off with a handy definition of machine learning:

“Machine Learning is an approach to learn complex patterns from existing data to make predictions on new data.”

Oh. Sure. Seems simple enough, right? But that doesn’t include generative AI, does it? As a matter of fact, it does:

• The existing data is what was used to train the model
• The new data is the prompt that is provided to the model (!)
• The response to the prompt is really a prediction when the model processes that new data (!!!)

Nick also outlined the anatomy of an AI use case:

1. Business Problem
2. Data
3. Training
4. Model
5. Accuracy Metrics
6. UX/UI

Which step is the most common stumbling block for organizations’ proposed use cases? The “Data” one—there needs to be sufficiently scaled, cleansed, and complete data to actually develop a model that is useful. Oh, and then that model will likely need to be refreshed and refined with new data over time.

The most neglected step in the planning of an AI project? The last step: actually thinking through what the user experience should ultimately be when the model is put into production!

Nick was quick to point out that it is easy to treat AI as a hammer and then seeing all the world as a nail. If there is a simpler, cheaper, equally effective way to address a particular business problem, then addressing it with AI probably doesn’t make sense! He also acknowledged (as did several audience members) that we’re currently at a point where there are executives who truly do just want to be able to say, “We use AI,” which means some projects can be a bit misguided. This phase shall pass, we assume!

Another discussion that cropped up was measuring the ROI of an AI use case. Nick noted that this can be shaky ground:

• AI technology platforms pushing to measure impact simply based on the adoption of the technology (rather than quantifying actual business impact)
• Minimal use of techniques like controlled experimentation to quantify the impact (there is simply too much excitement currently to create interest in withholding the magic from a control group in a disciplined way)
• The ROI of an AI project can be thought of as “the ROI of an OPEX project”—organizations that are disciplined about measuring the impact of non-AI OPEX projects should be pretty good about quantifying the impact of their investments; it’s just another tool in their toolkit, so the measurement mindset can be the same

And… there was more, including an example scoring matrix for prioritizing use cases across multiple criteria!

A recap post and the slides really can’t do the evening justice, but it’s better than nothing. The recap was above. The slides are right here:

And some pics from the evening:

We tried something a little different in this month’s DAW. We actually tried two things that were a little different in this event.

What we intended to be different was that we were going to have a panel of experts who would field a bunch of questions from the audience, capture them on a whiteboard, and then talk through them. Ultimately, we did that—not exactly as it had been drawn up (so to speak), but it worked out.

The unintended difference in the event was to see how many things could go wrong and still have us pull off a successful and engaging meetup. Speculation was that the questions and answers were going to be so good that our robot overlords became concerned and flexed their AI capabilities to undermine the meetup. To wit:

• On Monday, one of the three intended panelists pulled out of the event. No problem, Brian Sampsel was hastily recruited and graciously accepted the last-minute invitation.
• On Wednesday morning at 4:00 AM, one of the other panelists went into labor. Did she take the time to email us that she had become unavailable? Yes. Yes she did. Katie Schafer is a machine in her own right (as our other panelist, Pete Gordon, had already noted several days earlier). But, no problem. We could do this with two panelists. What else ya’ got to throw at us, HAL? Well…
• Weather anyone? The venue and the surrounding area had a tornado watch issued late afternoon, and the venue—Rev1—was squarely inside the tornado watch area. The tornado watch lasted until 7:00 PM (the event started at 6:30 PM). There was rain. There was wind. There was hail for Pete’s sake!

Apparently, though, analytics types take their cues from the USPS. Or have poor judgment. Or some combination? We wound up with a great turnout, with lots of good pre-talk discussion over pizza and beer:

Conveniently, the event is in the interior of the building! #tornadosafety

The discussion itself covered a wide range of topics—skewing heavily towards AI and less to date science (data science is involved in AI, of course, so it was still there):

A Range of Topics to Discuss

There is no deck to share, no recording, and this attendee didn’t take scrupulous notes, so we’ll go with a smattering of the discussion that could be retrieved from his brain the following day:

• When will AGI (artificial general intelligence) be achieved? Pete’s estimate (which seemed serious) was: 2033. But, he also noted that AlphaGo’s infamous Move 37 (in 2016) was a glimpse into that future.
• To RAG or not to RAG? Well… that’s a hot topic. It depends.
• Poisoning of training data? Why, and what are the ramifications? It sounds bad, but it’s got it’s uses—see Nightshade.
• Should newly minted software engineers be worried about AI making their jobs obsolete? No. Full stop. They’ll have some powerful new tools to employ, but their jobs aren’t going anywhere.
• What about marketing analysts? Will AI take their jobs? This prompted quite a bit of discussion. Brian made the point that AI can do some pretty impressive exploratory data analysis (EDA), which is definitely useful! One attendee asked if he could see getting to a point where you could tell an AI-based tool what your KPIs were, and it could then just analyze the campaign. The answer was, “Yeah… but a human still needs to set appropriate KPIs!” Even MMM came up—is that AI, or is that just… sophisticated linear regression (statistics). Kinda’ more the latter, but “AI” gets slapped on it for branding purposes and we get excited!

And, of course, lots and lots more! Some pics from the event:

This month’s meetup was our first since we were rechristened as “Columbus Data & Analytics Wednesday.” In an unintentional twist, the topic for the event was centered around the speaker’s contention that we (the broad, collective “we”) devote too much of our time and energy to the collection and management of data, and not enough effort to actually putting that data to productive and impactful use within our organizations.

Tim started out by calling out that, if we consider any task that has any relationship to data as “data work,” then we can further categorize each of those tasks into one of two buckets:

• Data Collection and Management
• Data Usage

He noted that there is no inherent business value in the collection and management data. There is only the potential for value. To realize that value requires putting the data to meaningful, applicable business use.

All too often, data workers get so caught up in data collection and management tasks, though, that they start to believe that there is inherent business value in those tasks alone. Tim pointed to three reasons for this happening:

• Technology vendors tend to have business models that are high fixed cost and low variable cost, which means they’re incentivized to drive aggressive customer growth. This results in heavy investments in marketing and sales organizations that wind up distilling down their messaging to, “Buy our technology and you will realize business value.” And they spend a lot of time and money promoting that message.
• Consultants have the opposite business model—low fixed costs and high variable costs—which means they grow profitably by selling engagements that use repeatable processes that can tap into a scalable workforce. That pulls them to “technology implementation” work over “deeply engage with the businesses of their clients and all of the complexity therein.” So, they wind up promoting a similar message: “Buy (our partners’) technology, let us help you implement it, and you will then realize business value.
• Human nature within organizations drives us to do tangible “things”—adding new data sources, cleaning up data quality issues, building or augmenting dashboards, etc. This leads us to telling ourselves that these tactical activities, which skew heavily towards data collection and management, bring value to the business in and of themselves.

According to Tim, recognizing and pushing back against this mindset means embracing the messiness and hard work required to actually use data productively. He proposed that organizations need to put the same level of rigor around their data usage processes as they put around their processes for collecting and maintaining data. As an example, he outlined a framework he uses (but was clear that this wasn’t “the only” framework that’s valid for data usage) that pointed to three distinct ways data can be used to provide value:

• Performance measurement—objectively and quantitatively answering the question: “Where are we today relative to where we expected to be today at some point in the past?” He described using “two magic questions” for this: 1) What are we trying to achieve, and 2) How will we know if we’ve done that?
• Hypothesis validation—this is all about improving decision making by reducing uncertainty when determining what to do going forward. For this, he described a 3-part fill-in-the-blank technique: “We believe [some idea] because  [some evidence or observation]. If we are right, we will [take some action].”
• Operational enablement—data when it is actually part of an automated or mostly automated process (for instance, ordering shoes online generates data that is used by the order fulfillment process). He went on to say that every generative AI use case he’s seen put forth falls into operational enablement.

He ended by imploring the crowd to look at the work they and their colleagues do day in and day out through a “data collection & management” vs. “data usage” lens and consider working to shift the balance of their efforts towards the latter!

The slides are available below, as well as at :

And, of course, some pics from the event, which had a large and lively showing!

Over fifteen years ago, Scott Zakrajsek was one of the founding organizers of Columbus Web Analytics Wednesday (he’s the guy in the green shirt right in the middle of this picture taken in May, 2008; three people in this picture, as well as the photographer, were present at our November 2023 event, and none of us could remember the name of the restaurant; the passage of time does wonders to one’s memories):

Several role changes, co-founding a company, spending several years in Boston before returning to central Ohio, getting married and having a couple of kids, and we finally convinced him it was time to re-take the stage at one of our meetups!

The topic: Google Analytics 4 and BigQuery. That’s a Big(Query) topic to cover briefly, but these two platforms are increasingly intertwined, as it has been evident for a while that Google has decided that the road to flexibility and robustness in accessing and analyzing GA4 data is a path that passes directly through BigQuery.

Scott provided a brief recap of how the fundamental data model in GA4 differs from Universal Analytics. He then made the case for why the ease with which that data can be piped into Google BigQuery (he outlined the steps for turning on that integration, including highlighting the key choices to be made when doing that) enables both deeper analysis as well as easier integration of website and mobile app behavioral data with data from other sources.

Once the data is in BigQuery, though, it has to be made accessible, both to analysts and to business users. For the former, that means SQL, and it means going beyond simply SELECT, FROM, WHERE, ORDER BY, and GROUP BY to also be comfortable with UNNEST, subqueries, and CTEs. He demonstrated how generative AI—Bard, as one option (which led to a brief discussion of Duet AI and Copilot as other options)—could be used to get an initial pass at functional SQL, although some tweaking is generally required. That led to a discussion of the difference between SQL-for-exploration-and-one-time-analysis vs. SQL-to-be-productionalized.

To wrap the session, Scott conducted a live demo, including pushing the results of a query into Looker Studio.

The presentation was followed by a great discussion that demonstrated the value of in-person meetups—attendees included both several individuals who are elbows-deep in GA4 with BigQuery as well as a number of BigCurious individuals who were able to tap into the experience of Scott and the attendees to get a much better since of what is involved in bringing the two platforms together.

More details? Check out the slides:

And, hey, the same guy who took that picture at the top of this post with 2008 digital photography tech has upgraded his gear a few times since then, so there are pictures from the event, too:

Bonus: in the intro, Bryan brought up the User Journey – Vol. 1 rock opera that long-time WAW co-organizer Jason Packer was instrumental in producing!

For this month’s event, Brett Buchanan from Pathfinder Product delivered a talk inspired by Jonah Hill and the documentary he directed centered on his friend and therapist, Phil Stutz. The inspiration for the talk was Stutz’s thesis that, in life, we are never free from pain, uncertainty, and constant work. If you have some pain (physical, psychological, emotional, or some other form that it pains me to say I cannot think of at the moment) and you address it, well, it just gets backfilled by some other pain. The same goes for uncertainty. And for work! Brett realized that this applies to businesses, as well as to our professional lives, as much as it applies to our outside-work world.

Step 1 is to recognize that. But, step 2—the gist of the evening’s talk—was that the way to keep this reality from forcing us to operate at indefinitely sustained levels of high stress is to bring a relentless focus to our work. At a high level, that “just” means figuring out what really matters (to you, to your organization) and then aggressively prioritizing the things that impact that (and let things that don’t impact that fall by the wayside). Going a level deeper, Brett walked through examples of organizations—Uber, CarNext, and Gap—and how they have applied this idea. He provided a useful way of framing a lot of buzzy/popular business management tools—north star metrics, OKRs, business process mapping—through this lens: applying them as a tool to gain that focus.

Do we have the slides? You can be certain that we do!

And does it pain you to ask if there are photos of the evening? No need! The posting of those flowed through our constant work pipeline and are available for your perusal should you wish.

Here at Columbus WAW, we’ve never claimed to be trendsetters, but we can hop on a bandwagon like a crowd of teenagers chasing a TikTok challenge.¹ The challenge? The landscape is evolving quickly, so we wanted to cover a topic that would provide content with staying power, and we needed a speaker who could do that! Luckily, Pete Gordon fit the bill, and he delivered (and he delivered while sporting a Columbus WAW shirt)!

His slides are available here. And, Pete himself can be found around town in all sorts of forums that he runs or supports, including GDG Columbus, Ohio DevFest (the next one will likely be in Toledo), and Columbus Code & Coffee.

While the talk danced into more technical territory than we generally get to at one of our meetups, it did so in the service of helping attendees think through the actual applications for this brave new world of large language models (LLMs). At this point, even the most non-technical of us have created an OpenAI account and lobbed some questions at ChatGPT. Maybe we’ve even tried out Bard. We’ve read more posts than we care to admit with Thought Leaders explaining 25 ways that YOU can put these tools to AMAZING USE! In short, we’ve lived “in the web interface” or “in the app” when it comes to exploring these platforms.

Pete’s talk, while relevant to this approach, came at the topic from more of a developer perspective—thinking about interacting with these platforms through their APIs. This included a glimpse into what this looks like, but, more importantly,  provided a perspective on the give-and-take of an application interacting with a large language model.

And, he framed the presentation around the greatest cartoon series ever created.

Midjourney (Perhaps) Successfully Avoids Copyright Infringement with Its Rendering of “Pinky and the Brain hunched over a computer and writing code. Both creatures have rounded ears, pink tails, and red noses.”

Before diving into Pinky-the-Prompt-Engineer and The-Brain-Doing-Embeddings-and-Vector-Similarity, Pete provided some background and history of natural language processing (NLP), noting that 2012-2013 was one big jump forward with the emergence of recurrent neural networks (RNNs), and 2018 was the next leap with the emergence of Bidirectional Encoder Representations from Transformers (BERT). He recommended attendees give Andrej Karpathy’s (co-founder of OpenAI) recent talk at the Microsoft Developer Conference on The State of GPT a watch.

For prompt engineering (the Pinky role), Pete emphasized that there is an important difference between the “base model” in one of these platforms and that base model actually being employed as an “assistant.” A base model is not an assistant, but, with effective prompt engineering, it can be made to behave as one! That prompt engineering certainly can be a human being (or a dopey mouse) who has read the right articles on the subject and then practiced to hone their techniques, or it can be an application that is designed to iteratively prompt a base model via API calls. The exact same concepts apply either way—a developer just needs to have codified the techniques!

Pete then shifted to explaining embeddings and vector similarity (the Brain side of things), where at least a few attendees’s minds (including the author of this summary) were blown. Unfortunately, much more of this was demo’d live with code than being available in his deck, which is why it’s always best to attend in person rather than rely on a mostly-human-written recap after the fact!

In a nutshell², when you have one of these large language models, you have a “model of unstructured data.” When you have other unstructured data (which could be a prompt, but it could also be just a statement or a document—some coherent string of words), you can use that as a query against the model to find out “where” in the model the data you’re passing in fits. That “where” can be represented with a vector of floating point values (think of those as being coordinates in an n-dimensional system that will melt your brain if you try to create a mental picture of it). “Yeah? So what?” you’re thinking. Well, that’s where things start to get pretty cool. If you’re working with a vector of numbers, then you can start doing “distance” comparisons of your unstructured data, be it other unstructured data you’ve passed into the model or unstructured data that exists within the model. The image above actually shows the resulting vector of floating point values when “Hello World how are you today?” was passed to the model. Then, the bottom part of the screen shows the sets of unstructured data within the model that are “closest” to that phrase (which Pete indicated were things like the “Hello, World” Wikipedia entry, since Wikipedia is one of the sets of unstructured data used to create the ChatGPT LLM). This part of the session prompted quite a bit of discussion as to potential use cases.

It was a broad, deep, and complex topic, but Pete kept it moving, and, as is the norm at these meetups, the audience was engaged!

Next month’s event will be tackling the same world of LLMs, but coming at them from an entirely different angle!

And pictures? Of course!

¹ The “like a crowd of teenagers chasing a TikTok challenge” line was provided by ChatGPT. Some of the other suggestions from our future overlord were: “like a kangaroo on caffeine”, “like a clumsy penguin sliding on ice,” “like a squirrel on a sugar rush,” “like a herd of cats chasing a laser pointer,” and “like a herd of wildebeests following the migration.”

²The post author does not make any guarantees regarding the accuracy of the contents of this nutshell.

With all of the focus on digital analytics platforms—Google’s impending end-of-life for Universal Analytics, privacy regulations, forced cookie expiration, and the like—it’s easy to forget that there is a world of data beyond platforms that do (or don’t…but then do again) report bounce rates and conversions. For our May event, Lindsay Peck, Conversion Optimization Director at Adept, explored two such types of data: heatmaps and session recordings.

Lindsay started by making the point that any self-respecting analyst, CRO, or marketer takes a fairly broad view of their data ecosystem and recognizes that different tools are useful for different types of data work:

She then elaborated on where these two specific types of tools fit in such an ecosystem: what they are, what they’re good for, and what their limitations are.

For heatmaps, well…we know what heatmaps are, right? In a digital context, they’re most often used to visualize where users are clicking (or tapping), how far down pages/screens they are scrolling, and, when working in a mouse world (desktops/laptops), where they’re actually moving the cursor before they click.

While heatmaps visually aggregate all of the users’ activities on a web page, session recordings capture individual users’ experiences on the site in a video format. Typically, these recordings are only captured for a (~random) sample of visitors to the site, and the analysis can be more time consuming. Lindsay recommended setting aside 2-4 hours for an initial review of session recordings—it’s got a lot of brain work involved to actually observe and process what is happening and “see” patterns across multiple recordings, so she recommended not trying to just fit the work into a series of 15-30 minute slots. It’s too deep work-y type work to do that!

There are lots of vendors that provide these engagement analysis features, with Microsoft Clarity being the option that is the most free and unlimited (although it’s functionality has some limitations) and hotjar being the most popular free/low cost (but you may need to be selective about which pages you capture data on). They are all typically pretty easy to implement—they can be deployed through a tag manager—but need to be considered through a privacy lens just like a digital analytics tool would be.

Some common uses for these engagement analysis tools are:

• Visualizing the most popular (hot) and unpopular (cold) elements of a web page
• Understanding what content users are seeing and engaging with (and sometimes, more importantly, what they’re not seeing or engaging with)
• Seeing where users are experiencing friction, hesitation, or possible frustration
• Understanding how users are scrolling and moving their mouse, and if they are interacting with your page’s main links, buttons, CTAs, etc.
• Supplying data and insights to inform a hypothesis around critical business and marketing questions like, why aren’t users converting, or why isn’t the CTA getting clicks?
• Uncovering and prioritizing bugs or display issues across devices.
• Putting yourself in your visitor’s shoes.

There was a lot of discussion throughout her presentation, which was fun! But, she also provided the slides if you weren’t able to attend and are content with reviewing those as the loosest approximation of having actually been there. If you’d been there, the gallery below shows some pictures of what you would’ve seen!

One of the benefits of having been running a meetup for 15 years and having awesome sponsors is that we are able to occasionally bring out-of-town speakers back by popular demand. It’s almost like we sometimes produce sequels, which, thematically, lined right up with this month’s event!

Lea Pica last presented at WAW in 2017, and we were beyond excited to bring her back to be on the in front of a big screen to once again provide attendees with tips and tales of storytelling done well..

This time, Lea wrapped her content in something of a thought experiment: what would happen if blockbuster movies and TV shows were delivered the way that most data presentations get delivered? For instance, imagine Game of Thrones as a corporate presentation:

“Game of Thrones” Reimagined as a Corporate Presentation

With that basic premise, Lea then shared five “Hollywood tips” for creating and delivering data presentations that are high impact:

1. Begin with an irresistible hook—think about movie posters that tease an upcoming release…and then revisit the title slide for your presentation
2. Learn to create anticipation—did you know that every TED Talk presentation is required to have a “throughline” identified—a single sentence that summarizes the entire talk? Put the effort in to determine the throughline of your data presentation, and you will be setting it up to be high impact and effective.
3. Take your audience on a journey of transformation—the “narrative arc” (exposition, rising action, climax, falling action, resolution) is part of cinematic and prose Storytelling 101 for a reason. It’s effective! Approach your data presentation as an Insight Journey existing within a narrative arc!
4. Present a clearly defined plan of action—S.M.A.R.T. recommendations are Lea’s twist on S.M.A.R.T. goals. In the context of recommendations, the acronym stands for: Specific, Measurable, Assigned, Relevant, and Time-Bound.
5. Conclude with a definitive ending—don’t the the presentation metaphorically just fade to black and drift off.

Whether you attended or not, you can request a really handy 15-page guide to these tips at leapica.com/wawhandout!

To demonstrate the impact of the approach, Lea shared at the end of the presentation that what she had delivered…had actually illustrated and applied all five tips. How meta is that?

The Narrative Arc Was Present in the Presentation We’d Just Witnessed

And, now, while it lacks a narrative arc, below are some pictures from the event!