Separating Algorithm Updates From Conduct

What the procedure has to produce

Start from the output, because it determines every choice upstream. A defensible separation produces four things: a dated timeline of ranking changes overlapping the damage window; a documented rule assigning the claimant's pages to an affected cohort and an unaffected cohort; a comparison of those cohorts across the event date, expressed in a metric the data actually supports; and an explicit statement of the portion of the decline the analysis does not explain.

That fourth item is not a concession. It is the deliverable. An opinion that quantifies a residual offers a testable claim with a stated limit, which is what reliable application looks like. An opinion attributing an entire decline to the defendant, in a window containing a confirmed Google update, asserts a precision no method in this field produces.

The inputs are equally short: the conduct date fixed to the day from the documentary record; Search Console exports covering the window plus a baseline; analytics sessions and conversions for the same period; a crawl or index record showing what changed on the site; the published ranking-update history; and, where available, dated snapshots of the results pages. Anything you cannot obtain becomes a line in the limitations section rather than an assumption.

Step one: fix both dates before looking at any traffic data

Fix the conduct date first, from documents rather than from the traffic series. Deployment logs, release notes, ticket histories, version control commits, termination letters, and change-approval records are the artifacts. Where the conduct is an omission — work not performed — the relevant date is when the omission began to have effect, usually a crawl date rather than a contract date, and that distinction should be stated.

Fixing the date from documents rather than from the chart matters more than it sounds. If you locate the conduct date by looking for the inflection in traffic, you have assumed the conclusion and every later test is circular. It is also the first thing a competent cross-examiner probes, because the answer is either "from the deployment record" or it is a problem.

Then set the damage window boundaries and the baseline. A baseline should cover at least the same calendar months in a prior year if seasonality is material to the category, which in retail, travel, tax, and education it always is. Note the hard constraint: Search Console performance data is a rolling sixteen-month window. If the baseline predates that window at the time of analysis, the first-party record no longer exists unless someone exported it contemporaneously, and no request to Google recovers it.

Step two: assemble the update timeline as an exhibit

Build a table, not a narrative. One row per confirmed ranking change whose rollout window intersects the baseline or the damage period, with columns for the name Google assigned it, the start date, the stated rollout duration, the end date, and the source. Google's Search Status Dashboard ranking-update history is the neutral artifact, and both sides should be working from the same table.

Two properties of that record do most of the analytic work.

Rollouts have duration. A core update — Google's term for a broad change to its general ranking systems — with a forty-five-day rollout means any inflection inside a six-week band is consistent with the update. Placing the conduct's effect on a single day inside that band claims a resolution the record does not carry. Report the band, and say whether the observed inflection sits inside it or outside it.

Updates overlap. Google has begun core and spam updates on the same day. Where two confirmed changes run concurrently with the conduct, the honest statement is that three candidate causes occupy one window, and the cohort comparison in step five is the only thing that can pull them apart.

Capture the dashboard entries the day you build the table, and record the capture method, because the page is live and will change.

Step three: label what is confirmed, what is observed, and what is rumor

The dashboard records the changes Google chose to announce. It is not a changelog of the ranking system, and Google ships continuous unannounced change that no public record dates. Sorting the timeline into three tiers keeps the report out of trouble.

• Confirmed and dated. A named update with a start date, a duration, and a publisher. This is a fact and it belongs in the exhibit.
• Observed but unnamed. A market-wide movement visible in data across multiple sites in a window with no dashboard entry. This is an inference from data. Show it, describe it as what it is, and do not give it a name Google never assigned.
• Rumored. Industry chatter about an unconfirmed change. This is not evidence, and a witness who calls it an update on the record has handed the other side a free cross-examination.

The asymmetry runs in both directions and neither side gets it for free. The absence of a dashboard entry is not proof that nothing changed; it is the absence of a confirmation. Equally, the possibility of unannounced change does not establish an algorithmic cause. Both propositions have to be shown in data.

Step four: use volatility data as corroboration and say so

Several vendors publish daily ranking-volatility indices, tracking positions for a fixed keyword set from fixed locations and devices and reducing each day's movement to a single number. A spike is treated in the industry as evidence that an update occurred.

Such an index supports one proposition: that the vendor's panel recorded unusual movement on particular dates. That corroborates a dated update, or suggests an undated one. It supports nothing about the claimant. Put the limits in the report in your own words, because they otherwise arrive in the deposition in someone else's:

• the keyword set is the vendor's, not the party's, and frequently not in the party's category;
• the locations and devices sampled are not the party's users', and the sampling frequency determines what movement is visible at all;
• the weighting is proprietary and cannot be audited by the opposing expert or by the court;
• the index measures the panel, not this site, and says nothing about why this site moved.

Third-party tracking data as the sole quantitative basis for a damages opinion is a real weakness, and Rule 702(b) is where it is felt. Placed alongside first-party data and a control cohort it is genuinely useful. Standing alone it is an argument in the shape of a chart.

Step five: define the cohorts, and write the rule down first

This is the step that decides the case, and it is the step most often performed backwards.

Define the affected cohort by mechanism, not by outcome. The affected pages are the URLs the conduct actually touched: the ones redirected, the directory disallowed in robots.txt, the template that lost its internal links, the pages that received a noindex directive, the section whose rel="canonical" tags were repointed. The unaffected cohort is drawn from the same site and the same period and consists of pages the mechanism could not have reached.

Write the assignment rule before you look at how each page performed, and record the date you wrote it. Selecting the affected cohort by picking the pages that fell is the most damaging single error available in this analysis, because it guarantees a result and the guarantee is visible to anyone who asks how the cohorts were chosen.

Match the two cohorts on what drives traffic independently of the conduct: query intent, pre-period impression volume, page type or template, topic, and age. Exclude pages created or removed mid-window, pages with their own concurrent changes, and pages too small to move a comparison. Then produce the full URL list of both cohorts as an appendix. If cohort membership is not reproducible from the report, the comparison is not testable — and an untestable comparison is exactly what Rule 702(d) analysis looks for.

Step six: run the comparison in metrics that distinguish the causes

Different causes leave different signatures, and reporting sessions alone destroys the information that separates them. Pull impressions, clicks, click-through rate, and average position by cohort by week, with sessions and conversions alongside.

• A ranking change typically moves average position while impressions persist — the pages are still eligible, they are placed lower.
• A crawling or indexing defect removes impressions entirely — the pages are no longer eligible at all.
• An interface change can leave impressions and position intact while clicks fall.

The comparison itself is a difference-in-differences: measure the change in the affected cohort from baseline to damage period, measure the same change in the unaffected cohort, and take the difference. The update hits both cohorts; the conduct hits one. The differential is the quantity attributable to the conduct, and the unaffected cohort's movement is your measurement of what Google did.

Then test it. Run the same model across a date on which nothing happened — a placebo — and confirm it produces no effect. Re-run with a plausible alternative cohort definition and report whether the result holds. Check the pre-trend: if the affected cohort was already declining relative to the control before the conduct date, the design does not support the attribution, and saying so early is better than being shown it later. Where a defect was remediated, test whether the affected cohort recovered on a schedule consistent with recrawling while the control did not.

Step seven: state what you could not control for

Write the limitations before the conclusion, as specific unmeasured quantities rather than boilerplate. The recurring ones: unannounced ranking change that no public record dates; competitor conduct not visible in the claimant's data; query-demand shifts within the window; the changing relationship between position and clicks as answers are delivered on the results page; and any period for which first-party data expired before preservation.

Then state the residual in a sentence a court can use. The form that works is arithmetic rather than rhetorical: the affected cohort declined by a stated proportion, the control cohort by a stated proportion over the same window, and the opinion attributes the differential — not the total — to the conduct.

Sometimes the correct output is that the available data does not separate the defendant's conduct from a concurrent algorithmic change. That is a result, not a failure. Under the amended Rule 702(d) inquiry it is a safer position than an opinion claiming a separation it never performed, because a stated limitation is a limitation and an unstated one is an overstatement.

The defense runs the same procedure

A defendant does not need a different method. It needs the same method, run honestly, and the discovery to run it.

Ask for the cohort URL lists and the date the assignment rule was written. Ask whether the conduct date was fixed from documents or located in the traffic chart. Re-run the comparison with a cohort definition the opposing expert did not use and see whether the result survives, and run the placebo test the report omitted. Pull the update history yourself and check whether every overlapping rollout window appears in the exhibit or only the convenient ones. Look for the pre-trend, because a decline that began before the conduct is the cleanest defense available and it sits in the same export.

The affirmative version is a decomposition too. If the unaffected cohort fell as far as the affected cohort, the claimant's own control has measured the algorithmic effect and left nothing for the defendant. If comparable competitors moved on the update dates by similar proportions, the market moved. And where the loss tracked a confirmed update across the whole site by topic rather than following the mechanism the defendant controlled, the footprint of the loss does not match the footprint of the conduct — a factual argument, made with the plaintiff's own data.

Frequently Asked Questions

Published 2026-08-11