Some of the most important work in publisher monetization happens outside of the spotlight. It happens between demand and engineering, between reporting and troubleshooting, and between the people building products and the people explaining the output to the business.
That’s the part of the organization I’ve spent years working in, and it’s shaped how I think about support, leadership, and the limits and possibilities of automation.
The Unlikely Path That Built the Right Perspective
Like many people in adtech, I didn’t come into this role through a neat career ladder — and that’s actually an advantage. I started out in linguistics and teaching, moved into copyediting at an early internet publishing company, and then into a webmaster role at a statewide college application service.
The standards there were high because if something broke, students couldn’t apply to college. The website, analytics, user experience, content, and a large program database all existed in the same orbit. That mix taught me to look at digital problems from more than one angle at once — how audience, content, data, and operations affect each other — long before I became aware of adtech.
Then I landed at an adtech company, handling demand relationships, technical and data integrations, troubleshooting, onboarding, ad quality, and performance analysis — effectively three teams’ worth of work.
That breadth is what I bring to Freestar now. I can sit between teams, see how one decision affects another, and understand what one group will need from the next before the handoff happens. In a larger company, that connective view is easy to lose, and it’s probably the most valuable perspective I have.
Where Reporting, Demand, and Troubleshooting Intersect
I lead two teams inside Freestar’s support division.
The data support team handles the questions that come in when reporting looks wrong. They explain what can be explained, escalate what needs to be fixed, and work closely with engineering on projects that shape how data is collected and reported in the first place, including quality assurance (QA) on data initiatives, new partner reporting, fixes when partner reporting breaks, and input on larger efforts like unified analytics.
The demand support team focuses largely on ad quality. If a publisher sees an advertiser it would rather avoid, a format that detracts from user experience, or content that shouldn’t be on the page, that ticket comes to us. This team also investigates, escalates issues to partners, and advises product and engineering teams on integrations, auctions, IDs, and the trade-offs that come with each setup.
Since my teams are close-knit, I’ve always been a hands-on, working manager. My approach has been to coach people, give them the skills and context they need, and then let them do the work. That comes directly from my background in teaching, and it’s even more important when the team is lean.
On AI, Automation, and What My Team Is Teaching Me
This is where I have to give credit where it’s due: My team has been leading me here, not the other way around. As a leader, I’m always energized when my team proves me wrong and goes beyond what I thought was possible, and the ideas they’ve come up with for AI have genuinely surprised me.
I’ll admit I’ve been cautious. When you’ve seen enough edge cases, you get a feel for which problems are actually repetitive enough to automate, and much of what my teams do requires human judgment. Ad quality tickets, reporting anomalies, and cross-functional troubleshooting depend on pattern recognition built from years of seeing how publishers, partners, products, and integrations actually behave in the real world.
How We’re Already Using AI
We use AI to help build and fix SQL queries and to draft messaging, emails, documentation, and summaries — keeping them concise and clean. We use it to search Slack, email, and tickets for similar past cases when starting an investigation, because we may have encountered the same issue before.
We also use AI to do deep dives into our own documentation and codebase, so what might have taken hours to answer before can sometimes be resolved in seconds. We also use it to explain whole sections of our codebase and data architecture in plain language, not just for active tickets, but to improve our own understanding of how our systems work. And we’ve started using it to get advice on building better investigative tools, or improving the ones we already have.
Internally, I’ve started using it as a kind of personal assistant — tracking deliverables, action items, and things I need to follow up on across conversations that might otherwise fall through the cracks.
Potential AI Use Cases for the Future
We’re also experimenting with what should come next, i.e. whether AI could help pull data from third-party sources for ingestion into our internal databases.
Meanwhile, we’re striving for smarter analyzers for HAR files and other exports, and while our current tools pull out specific details, we think we could better train AI to find deeper insights
We’re also looking into whether there’s a more efficient way of reproducing a bad ad to diagnose it, which currently means watching a site for minutes or hours until the ad happens to serve. We’re looking at ways an AI agent can do that monitoring for us and export the screenshot automatically. And then we’d also like give publishers an AI tool that captures what we need when they spot a bad ad — instead of just a screenshot — so we can investigate more efficiently on our end.
None of that work is glamorous. It lives in the middle, translating business needs into product requirements, resolving issues quickly, and helping teams understand how their decisions land for publishers. But it’s also where the most consequential things get decided, often without anyone noticing.
The people who understand how the whole system fits together — and who are willing to keep learning what that system can do — are among the most valuable in adtech, precisely because they’re so easy to overlook.
