--- name: eulerian-marketing-platform-audience-report-analysis description: Build a traffic and audience picture for a chosen period from Eulerian batch reporting, choosing dimensions and metrics deliberately, then reading the result for trends, segments and anomalies before drawing conclusions. Read-only exploratory analysis of site behaviour. Use when the user asks who visits the site, where traffic comes from, how audience composition changed, which segments behave differently, or asks for an audience or traffic overview for a period. --- # Analyse audience and traffic in a period The goal is a **picture of who the audience is and how it moved**, with every claim tied to a figure you actually pulled. This is exploratory work: you read, aggregate and compare. You do not change anything in the account. Outcome questions (goals, sales, carts) belong to the conversion review job; if the user drifts there, say so and switch. ## 1. Pin the scope before querying Confirm with the user, and state back in one line: - **The website or site identifier** the analysis covers. Confirm it with `getallowedwebsite_account` first. Analysing the wrong site is the most common and most expensive error. - **The period** (start and end dates, time zone if the user cares) and the **comparison period** if they want change. "Last month" is ambiguous; write the exact dates. - **The question**: composition ("who"), sources ("where from"), trend ("how it changed") or anomaly ("what spiked or dropped"). The question picks the dimensions. Do not pull everything. If the user has not said which website, stop and ask. Do not infer it from the first result. ## 2. Discover what is available, then choose Use `kinds_batch_reporting` and `dimensions_batch_reporting` to see the dimensions that exist for batch reporting. Choose a small set for the question: - **Composition:** one or two audience dimensions at a time (device, browser or operating system, country, new versus returning, channel). Crossing more than two multiplies the rows you have to read and the chance of tiny, noisy cells. - **Trend:** a time dimension at day or week grain, with one headline metric. - **Sources:** a channel or referrer dimension, checked against volume. Get the metric names from the same discovery calls, or from `how_to_query_flat_aggregate_batch_reporting` if you need the query shape. Do not guess metric names. Run the aggregation with `flat_aggregate_batch_reporting` or `mcp_analytics_batch_reporting`. Use the flat aggregate tool when the answer is a single summary table; use the batch tool when you need a series over time. ## 3. Check the numbers before you read them Before any interpretation, sanity-check each result: - **Totals reconcile.** The sum of a breakdown should match the overall total for the same period and metric. If the parts do not add up, the cause is usually a filter, an unknown or unset bucket, or a different metric definition. Find out, do not paper over it. - **Small bases.** A segment with a handful of visits can swing from 0% to 50% on one visitor. Report the base alongside every rate, and do not rank segments on rates when their bases are tiny. - **Period length.** A partial day, a partial week or a holiday in one period but not the other makes the comparison invalid. Name it. - **Data gaps.** A zero day may mean no traffic or no data. Check whether the tracking was live. Say which you believe. - **Empty results or permission errors.** Report them as findings about the query, not as "the audience is empty". See the essentials skill for permission handling. ## 4. Read for trends, segments and anomalies, in that order - **Trend:** compare the headline metric across the period and against the comparison period in absolute and relative terms. Name the direction and the size. Note whether it is steady or driven by one or two days. - **Segments:** find where the total moves. A 10% overall drop that is entirely one browser is a different story from a broad decline. Rank segments by contribution to change (volume times rate change), not by the largest percentage. - **Anomalies:** a day or week far outside its neighbours. Ask what could cause it before explaining it: a campaign, a deploy, a holiday, a bot burst, a tracking change. A single outlier with no supporting pattern is a question for the user, not a conclusion. - **Sources:** distinguish volume from quality. A channel that grows in visits but not in share of the audience is less interesting than one whose composition shifts. Separate what the data shows from what you infer. "Mobile share rose from 48% to 61%" is shown. "Users switched to phones because of the new app" is inferred and must be labelled as such. ## Common patterns and traps - **Ranking by rate on tiny bases.** The top segment by conversion or engagement is often a 12-visit group. Always show the base. - **Confusing visits with visitors.** Dimensions and metrics may count different things. Use the wording the platform uses and keep the unit consistent across comparisons. - **Comparing unequal periods.** A 31-day month against a 28-day month, or a bank holiday against a normal week. Normalise or name it. - **Reading a spike as a trend.** One high day followed by normal days is an event. Check the days after it. - **Over-slicing.** Five crossed dimensions give hundreds of cells, and some will look dramatic by chance. Cut the question down before you cut the data. - **Silent scope change.** Switching site or period mid-analysis and reporting the combined result as one picture. Keep scopes separate or state the change. - **Mistaking a tracking change for an audience change.** A new tag, a consent-banner change or a renamed page can shift counts sharply. Ask whether anything changed on the site or in tracking that period. ## Output ``` Scope: , vs , question: Data checked: totals reconcile ; small bases ; period length Headline: Trend - : vs (), Segments (ranked by contribution to change) - : , , base , Anomalies - : , possible causes to check: Inference (not shown by the data) -