Marketing Analytics

Meet the Team

Leadership

• Djordje Micovic, Senior Manager, Marketing Analytics

Team Members

Each functional marketing team has a designated point of contact with Marketing Analytics team member:

Team Mission

We exist to help GitLab’s marketing organization make better decisions - not just report on what happened, but explain why it happened and what to do about it.

Our job is to close the gap between what the business needs to know and what it currently sees. That means building reliable data infrastructure, yes - but it also means proactively surfacing insights that change how leadership allocates resources, evaluates programs, and sets strategy.

We measure our impact not by the volume of dashboards we maintain or requests we close, but by the decisions we influence and the dollars we help redirect towards better outcomes.

How We Work

We are a small team supporting a large surface area

We are a small team supporting marketing functions across demand generation, web analytics, sales development, product-led growth, brand, events, developer relations and more. We operate on a Snowflake/dbt/Tableau/Salesforce stack, with deep integrations into Marketo, Bizible, and GA4.

Because we’re small, how we spend our time matters. We prioritize ruthlessly, we push back when we need to, and we invest in building things once so we don’t rebuild them every quarter.

Async-first, with intentional sync

We work across multiple time zones. Most collaboration happens asynchronously through GitLab issues, Slack, and shared docs. We sync in team meetings to align on priorities, share context across domains, and tackle the big questions we can’t answer alone.

We schedule Slack messages rather than expecting immediate responses. We document decisions in issues, not in DMs.

Domain ownership, shared curiosity

Each analyst has primary domain ownership. But we don’t treat domains as walls. The best insights come from connecting data across the funnel: what’s happening on the website, how that flows into MQLs, how those convert through sales, and what revenue comes out the other end.

If you’re working in your domain and spot something that affects another domain, say something. If you want to explore data outside your usual scope, you have full permission to do so - even outside of the marketing data.

AI development

We develop agentic tools and AI skills collaboratively, using our team’s GitLab repository as the single source of truth for all code. The principle is simple: when someone on the team builds a useful prompt, skill, or agent workflow, it doesn’t live on their laptop - it goes into the repo so everyone can use it, learn from it, and improve it.

We iterate on these skills together, and every addition or change to the repository requires a peer review before merging. This keeps quality high, spreads knowledge across the team, and ensures we’re building shared capability rather than individual shortcuts. We follow the Data Team standards for agentic tool development as our baseline, and extend them where our team’s use cases require it.

How to Get Us to Help

Start with a GitLab issue

All requests should be submitted as GitLab issues. This is non-negotiable because Slack threads disappear, context gets lost, and we can’t prioritize what we can’t see.

Everyone should be empowered to create an issue with our team. If you need help, we’ll work with you to get it right. A well-written issue gets resolved faster. We regularly review and assign issues to team members based on capacity and domain. Unassigned issues trigger weekly alerts through our custom triage bot.

Only in some rare cases when the request comes from senior leadership (VP+) we’ll create the issue on your behalf based on a brief conversation or Slack thread if you provide us with a live context and requirements.

We strive to have all completed team work in an associated GitLab issue.

What makes a good request

A request we can act on quickly includes:

• The question you’re trying to answer - Not just “I need a dashboard” but “I need to understand whether X is working so we can decide Y”
• What decision this will inform - If you can’t articulate this, the request probably isn’t ready
• Which Company Objective this request is supporting - If you can’t highlight a shared objective of your leader that this work is supporting, it’s not going to be prioritised.
• Relevant context - links to campaigns, UTM parameters, asset lists, time periods, audience segments. The more you give us, the less back-and-forth we need
• Timeline - when do you need this, and what’s driving that date?

Prioritisation

Our priority stack

We evaluate all work against a simple hierarchy:

1. Team objectives - These are the things we’ve committed to deliver for the quarter, aligned to company-level goals. They come first, always.
2. Leadership-flagged priorities - Work that senior leadership has explicitly identified as critical, even if it’s not in the objectives. This is usually tied to an executive request or a time-sensitive business need.
3. Stakeholder requests aligned to team objectives - If your request supports something we’re already committed to delivering, it gets prioritized naturally.
4. Ad hoc requests - Everything else. We’ll get to it, but not at the expense of items 1-3.

How we say no

If your request doesn’t align with our current objectives and isn’t flagged as a priority, we will tell you - respectfully and directly. We’ll explain what we’re working on, what we’d need to deprioritize to take on your request, and offer alternatives where we can.

This isn’t personal. Saying no is how we protect our ability to deliver on the things that matter most to the business.

If you disagree with our prioritisation, escalate to our manager Djordje Micovic and provide a case why your request should be reprioritized.

When it’s actually urgent

Real urgency exists - a data incident, a broken dashboard before an executive review, a last-minute board request. When that happens, ping our #mktg-analytics channel. We will reprioritize. But “urgent” means the business is impacted today, not “my stakeholder wants it soon.”

Team Principles

These are the operating agreements we committed to as a team. They’re not aspirational corporate values - they’re practical norms we hold each other to.

1. Have each other’s backs

We are each other’s first call, not last resort. When you’re stuck on a stakeholder conversation, struggling with a data model, or unsure how to prioritize - reach out to the team before you spiral. We are not a group of individuals who happen to share a manager. We operate as a unit.

Practically, this means: share context proactively, step in when a teammate is overloaded, and never let a team member find out about something important from a stakeholder before they hear it within the team.

2. Discovery before solution design

When a request comes in, take a beat. Understand what’s actually being asked and why before committing to a deliverable. We’ve burned too many cycles building something fast only to find out nobody needed it, or the real question was different from the one stated.

Ask: What decision will this inform? What will change based on what we find? If the answer is unclear, push for clarity before committing to work.

3. Be a manager of one

Each person on this team is trusted to manage their own work. You know your priorities, you know our objectives, and you know how to judge whether an incoming request is urgent or noise.

If it’s on the team objectives or your manager has explicitly flagged it - it’s a priority. If it’s not, you’re empowered to say no, defer, or escalate. When you’re unsure, bring it up - but bring your recommendation, not just the question about the prioritisation. Operating at a high level requires prioritisation judgment, and we strive our team to be able to do so.

4. Quality over volume - especially with AI

We use AI tools aggressively to move faster. But everything that leaves this team must be proofread by a human. No AI-generated slop in issues, Slack messages, or deliverables. If the person reading it can tell a machine wrote it and nobody reviewed it, it’s not ready to send.

The standard: Is the answer very long without substance? If you are being honest - is it a complete answer or half baked AI analysis? Strive to improve your skill set leveraging AI, not AI to do the work.

5. Insights that change decisions

A dashboard that shows a number going down is operational reporting. An analysis that quantifies the revenue impact of that decline and recommends a specific course of action - that’s what we’re here for.

We’re building toward a team that doesn’t wait to be asked. We see something broken, we investigate, we frame the business impact, and we put it in front of the right people.

Our Work

We publish self-service dashboards to help teams understand key marketing KPIs. Our dashboard page lists our supported dashboards and the framework for publishing a new one.

Our Dashboards are based on the metrics defined in our Marketing Metrics page.

What We Support

We build dashboards and reporting using GitLab’s Enterprise Data Warehouse (EDW), including:

• Source of Truth (SoT) Tableau dashboards
• Ad-hoc reports in Snowflake and Tableau
• Ad-hoc investigations in Google Sheets

We don’t support SoT or campaigns based Dashboards in Salesforce.

We are the Business Owners Of the Following Applications

• Bizible
• Allocadia
• Google Analytics
• Hightouch

To request access please follow the access request process as outlined in the business operations handbook. If you are working with a contractor or consultant that requires access to one of these tools, please follow the professional services access request process as outlined in the procurement handbook.

Important Resources

• Marketing Metrics
• Dashboards Page
• Marketing Analytics Data Overview and General Information

View page source - Edit this page - please contribute.