Written answers to the questions buyers actually type. Each one opens with a summary that stands on its own, and is dated so you know how current it is.
Every account is eligible. That is not the same as every account having enough data for the model to say anything.
Google states that all conversion actions are eligible for data-driven attribution regardless of volume, and separately recommends at least 200 conversions and 2,000 ad interactions in a 30-day period for the model to perform well. Those two sentences are doing different jobs, and the gap between them is where most mid-market accounts sit. This works through what the recommended volume costs in real spend, what happens below it, and what to do instead.
The first thirty days is the most expensive month of the engagement and the one most agencies give away.
Onboarding is real delivery work with a real cost, and waiving it converts the start of every engagement into an investment with a payback period. Compute that period explicitly: setup cost divided by monthly contribution tells you how many months a client has to stay before you are whole. Then decide deliberately whether to charge, amortise, or absorb, rather than defaulting to absorb because a competitor's website says onboarding is free.
Nobody decides to waste bench time. It gets wasted because no decision was made while it was happening.
Bench time is capacity you have already paid for, so it cannot be saved, only spent. The failure is not that it exists, it is that the spending decision is made by default and after the fact. This article prices a bench day from your own cost base, ranks the realistic uses by what each one actually returns, and sets out the rule that keeps a short bench from becoming a long one.
The client said yes on a call. That covers none of the four things you were about to do.
Publishing work is governed by three separate permissions that agencies routinely collapse into one: naming the client, stating a result, and quoting a person. Each has a different approver and a different standard. Naming is a marketing decision, stating a result is a claim that has to be supported by a test done beforehand, and quoting a person involves their personal information. Ask at the right moment, in writing, and record what was actually approved.
The banner is not the implementation. The banner is the part everyone can see.
Consent mode communicates a visitor's consent choices to Google so tags can change what they do. Version two added two advertising parameters to the original storage ones. The decision that matters is basic against advanced: whether tags are blocked entirely until consent, or loaded in a restricted state that still allows modelling. Most failures are not policy failures, they are ordering and scoping mistakes in the implementation.
A gate nobody can pass in under a week is a gate teams learn to route around.
Regulator guidance asks organisations to assess privacy risk on all new projects involving personal information and on any new collection, use or disclosure, and to build a review and approval process that involves the privacy officer when new initiatives are designed. Translating that into a delivery workflow means one gate, a fixed set of questions, a named approver and a service level, placed before build rather than before launch.
The product data specification lists dozens of attributes without ranking them. Working through it top to bottom is how a feed project takes six weeks and still gets disapproved.
Google's product data specification marks attributes as required, it depends, or optional, and that is the only ranking it gives you. In practice the attributes divide into three tiers by consequence: ones whose absence stops the item serving at all, ones whose wrongness gets the item disapproved after it has already been submitted, and ones that only affect how well the item competes. Fix them in that order, because the second tier is where the expensive surprises live.
Most agencies who build against this API did not need to. Most who needed to waited two years longer than they should have.
The Microsoft Advertising API is well documented and genuinely usable, which makes it easy to build something you did not need. The decision turns on a small number of things: how many accounts you touch, whether the work is reporting or writing, and whether anyone will maintain it in eighteen months. There is also a hard platform date now in play, because the SOAP interface has a published retirement schedule, and that changes the arithmetic for anyone already integrated.
The problem with a seasonal account is not the season. It is the eight months of nothing that sit in front of it.
A business that advertises for one season a year has a structural problem no always-on account has: every campaign restarts from a long gap, and the conversion data that automated bidding needs is months stale before the season opens. The fixes are structural rather than tactical. Keep the learning boundary alive where you can, plan the ramp as part of the season rather than as a preamble to it, and know what seasonality adjustments are actually built for, because it is not this.
The keyword question and the ad copy question have different rules, and most arguments about this conflate them.
Bidding on a competitor's name involves three separate decisions that people routinely treat as one. Google's advertising policy allows trademarks as keywords but restricts them in ad text. Canadian law is not concerned with the keyword at all, it is concerned with whether the representation your ad makes is false or misleading in a material respect. And the commercial question, whether the traffic is worth what it costs, is usually the one that decides it. This is an operational read of the three, not legal advice.
You do not need to read ABAP. You do need to know why a two-line change takes three weeks.
A delivery lead on an SAP programme does not need to write ABAP, but needs enough literacy to test an estimate and hear a risk. Four concepts carry most of that: what ABAP actually is, why transports rather than deployments move code, what a release contract means for whether SAP can break your extension, and what the code quality tooling tells you about the state of a custom estate.
Both can do the job. Only one of them can be changed by the person who will be here when it breaks.
Apex triggers and Flows overlap heavily, and the capability comparison is the least useful way to choose between them. The decision that matters is who maintains the automation after the person who built it has moved on, plus a second consideration nobody plans for: when both fire on the same object, the interaction is hard to reason about and harder to debug. This gives concrete criteria, the ordering problem, and a rule for mixed estates.
The first surprise bill is never caused by a missing budget. It is caused by somebody believing a budget was a limit.
Azure gives you budgets, cost alerts, tags and the ability to pause a capacity, and only one of those four stops money being spent. Budgets notify, they do not cap, and they evaluate on a cycle slow enough that a runaway job can spend for a day before anyone hears about it. This piece separates the controls that inform from the controls that act, works through what the evaluation delay actually means for a small team, and sets out the three decisions that change an analytics bill: allocation you can read, a schedule for anything periodic, and an owner who sees the number.
Most charters are read once, by the person who wrote them. That is a format problem, not a discipline problem.
A project charter exists to record the decisions that authorize a project: who sponsors it, what it is for, who can say yes, what is explicitly out, and what success will be measured against. A charter that runs to twelve pages of background is a document nobody consults under pressure. The version that works is one page, written as decisions rather than narrative, and signed by the person who controls the budget.
Every chart Jira draws is a rendering of one configuration choice. Most teams have never seen the screen where it is made.
Estimation in Jira is configured in one of two different places depending on the project type, and every sprint chart is a rendering of that choice. Three details cause most of the confusion: estimating and tracking are separate settings, subtask estimates are excluded from the velocity and burndown charts, and changing the method mid-engagement produces a chart with a step in it that nobody can explain later.
The board is a decision rule with names attached. The meeting is optional and usually wrong.
A change advisory board reviews and approves higher-risk changes. At enterprise scale that means a standing weekly meeting with a dozen attendees. At three people it should mean a written routing rule, a named approver per change class, and a review that happens asynchronously against a deadline. The control that matters is a second pair of eyes with the authority to say no, and that does not require a calendar invite.
Nobody can look at a dataset and tell you it is right. That is the whole problem, and it is solvable with numbers.
Analytics deliverables have no visible surface to approve, so acceptance defaults to a client glancing at a dashboard and saying it looks fine. That is not acceptance and it will not survive a disputed invoice. Every analytics deliverable can be made testable with three ingredients: a named comparison source, a stated numeric tolerance, and a stated window.
A retrospective with the client in the room is not a retrospective. It is a meeting where nobody says the true thing.
Scrum's four ceremonies differ in whether an outsider changes what gets said. The sprint review is designed for stakeholders and should have the client in it. The retrospective is designed for candour and does not survive an audience. The standup is a working meeting that clients turn into a status round. Planning is conditional. Decide access per ceremony, say the rule out loud at kickoff, and give the client a better channel for what they actually want.
Separate what is documented from what is assumed. Almost every bad decision in this area lives in the gap.
AI-assisted analysis fails in ways that look like competence: a plausible number with no source, a definition quietly substituted, a conclusion that matches the framing of the question rather than the data. None of these announce themselves. This is a catalogue of the failure modes with a detection step for each, and a deliberate line drawn between behaviour that vendor documentation actually establishes and behaviour people infer from a good demo.
The daily job pulls one day. The backfill pulls eleven hundred. Running the same code a thousand times is how you get banned for a week.
A backfill fails for one of three reasons: it exceeds a daily quota and stops, it retries so aggressively that the platform throttles you harder, or it dies at hour nine with no record of what it already loaded. All three are design problems rather than bad luck. Chunk by a natural key, cap concurrency below the documented limit, back off with jitter, checkpoint every chunk, and load newest first so a partial result is still useful.
Every platform reports how many people have a licence. None of them reports how many people stopped keeping their own spreadsheet.
Licences assigned, dashboards published and total view counts are the three adoption metrics most organisations report, and all three go up whether or not the platform is working. The measures worth tracking are repeat usage, time since last login, breadth of active content, indirect engagement through subscriptions, the decay curve after launch, and the count of parallel spreadsheets still in circulation. Five of the six come out of the platform. The sixth has to be asked for, and it is the one that tells you the truth.
A blend is not a SQL join. It aggregates first, joins second, and that order is where the numbers go wrong.
Data blending is the most used feature in Looker Studio and the one that produces the most quietly wrong reports. The reason is structural: each table in a blend is grouped and aggregated before any join happens, so identical rows collapse and the blend can return fewer rows than the same join run in SQL. Add a default left outer operator, metrics that arrive as unaggregated dimensions, and blends that cannot be reused outside their own report, and you have four failure modes that all look like a client typo. This names each one and gives the check that catches it.
The tag manager was sold to the business as a way to avoid waiting for developers. That is exactly what it does.
A Custom HTML tag is unreviewed JavaScript running on every page of a production site, deployed by whoever holds publish rights on the container. Nothing about the marketing framing changes that. Google provides two mechanisms that fix it: custom templates, which run sandboxed with declared permissions, and a page-level policy API that lets the site itself refuse what a container asks to do. Most organisations use neither.
The setting is on. The domain is listed. The parameter still never arrives, and every crossing starts a new session.
Cross-domain measurement keeps one visit as one session when a person moves between domains you own. GA4 does it by appending a linker parameter to the outbound link, which the destination page reads to continue the session. Configuring the domain list is the easy half. The failures are downstream: redirects that drop query parameters, scripts that stop the click event propagating, and navigation triggered by JavaScript rather than by a link.