Measuring whether the agent's writing earned anything
An agent that publishes without a feedback loop is writing post forty the same way it wrote post one. Closing the loop takes a stored measurement window and a reader that groups by decisions.
Measuring what an agent's writing earned takes two steps that are deliberately separate. First a sync runs the GA4 and Search Console reports for one date window and stores a row for every post either report mentioned. Then a reader groups those stored rows by the decisions behind each post and reports what each group earned. The step that makes the answer honest is in the storage: a post no report mentioned is counted as unmeasured rather than written as a zero row, because a post nobody visited and a post no report covered are different facts.
A zero says the measurement happened and found nothing. An unmeasured says the measurement did not cover this post. Collapsing the two produces a report that quietly punishes every post published near the end of the window, every post on a page the report did not reach, and every post measured while one of the two connections was missing. In Market4's scorecards the sync returns an unmeasured count alongside the rows it stored, and each row carries a sources field naming which reports actually contributed, so a zero in a column can be read for what it is.
The same rule applies to reading one post's history. An empty scorecard list means no sync has covered that post yet, not that the post earned nothing. It is the difference between an unanswered question and a negative answer, and an automated writer that cannot tell them apart will keep rewriting pages that were never measured while ignoring pages that genuinely failed.
The sync is the part that costs something. It reads Google, so it spends Google quota, and it is the write that every later read depends on. That argues for running it once per window rather than once per question: one sync of last month's data serves every question anybody asks about last month. The readers cost nothing, because they read what the sync stored. A thin report therefore means a thin sync history rather than a thin archive, which is a diagnosis you can act on.
| Call | What it does | What it costs |
|---|---|---|
| Sync a window | Runs GA4 and Search Console for one date range and stores a row per mentioned post | Google quota; run once per window |
| Read one post's scorecard | Every stored window for that post, newest first | Nothing; it reads stored rows |
| Read the learnings | Groups stored rows by the decisions behind each post | Nothing; it reads stored rows |
A consent banner changes what GA4 can measure, and the reports carry no marker saying so. What the seven consent types cover, what basic and advanced consent mode each do when someone declines, and how to read numbers collected under either.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Both readers being optional is a design decision rather than a limitation. An app with only Search Console connected gets half a scorecard, which is more than it had, and the sources field is what stops that half being mistaken for a whole. Waiting until both connections exist before measuring anything is how a blog reaches its fiftieth post with no history at all.
The learnings reader groups posts by things the writer chose: title length, word count, tags, whether the post carried FAQ blocks, whether it carried a table, and whether it declared a target keyword at all. Those are the levers an agent controls on the next post, which is the point of grouping by them. The output is not advice from somebody's article about ideal content length; it is what this blog's own archive earned, measured on this domain, for this audience.
Declaring a target keyword is the decision worth checking first, because it is the one that makes several other reports capable of saying anything. A post published with no declared target has nothing to be measured against when the question is whether it won the query it was written for, and the report says so rather than guessing which query was intended.
Grouping stored measurements by decisions produces correlations, not experiments. Posts with tables may earn more because tables help, or because the topics that deserve a table are the topics people search for. Nothing in the grouping separates those, and reading it as causation is how a blog ends up with a table on every page. Treat a group difference as a question to test on the next batch, keeping the rest of the decisions steady, rather than as a rule to apply everywhere at once.
Once per window you intend to ask questions about, and no more, because the sync is the call that spends Google quota while the readers are free. A monthly window suits a blog publishing a few posts a week; a weekly window suits a heavier schedule. Re-syncing the same window repeatedly costs quota and changes little, since the underlying reports settle after Google finishes processing the days in range.
Long enough for the page to be crawled, indexed and to accumulate impressions, which is weeks rather than days for a new post on an established site and longer on a new domain. A scorecard read on the day of publication tells you almost nothing, and an empty result at that point means the sync has not covered the post yet rather than that the post failed. Measure the window, not the hour.
It can narrow the choice, and it should not make it alone. The stored rows say which decisions coincided with more impressions and clicks on this blog; they do not say which topics matter to the business, which claims are safe to make, or which page a customer asked for. A useful arrangement gives the agent the numbers and keeps the choice of subject with a person who knows what the product is for.
They usually will, because they count different things: Search Console counts impressions and clicks on Google's results, GA4 counts sessions on the page from every source. A post with clicks and no sessions points at a measurement gap on the page; a post with sessions and no impressions is being found through links, email or social rather than through search. The disagreement is a finding, and the sources field is what lets you read it.
A signup that starts on your marketing site and finishes in your app is two users in GA4 unless the domains are configured together. Here is what the setting does and what it cannot fix.
A mention with no hyperlink cannot appear in a referral report, because attribution needs a click that carries a referrer. The measurement that does work is a branded-query baseline in Search Console, taken before the mention runs.