# Wikipedia Topic Attention Monitor

Compare two seven-day Wikipedia pageview windows for exact article titles. Export fourteen dated observations, totals, changes and evidence URLs. Pageviews are not unique readers or sentiment.

Canonical product page: https://mayd-it.com/data-tools/actors/wikipedia-topic-attention-monitor/

## Example input

```json
{
  "articles": [
    "OpenAI"
  ],
  "maxResults": 1
}
```

## Full guide

# Wikipedia Topic Attention Monitor

**See how attention to an exact Wikipedia article changed between two weeks.** Enter one to ten titles or article URLs. Each saved row includes fourteen dated observations, two seven-day totals, an arithmetic change and the official evidence URL. No API key, browser or paid data service is required.

## Try a small watchlist

```json
{"articles":["OpenAI","YouTube","TikTok"],"maxResults":3}
```

Omitted or empty articles use the same three titles on `en.wikipedia.org`. The default end date is three days before today in UTC, allowing time for data publication. An explicit `endDate` fixes the comparison; otherwise the windows roll each day. The dataset and **Run report** show the actual boundaries. `maxResults` defaults to ten, while the default watchlist contains three articles.

## What the comparison means

Both windows contain exactly seven UTC dates. The current window ends on `endDate`; the prior window ends one day before the current window starts. `viewChange` is current total minus prior total. `percentChange` is `100 * viewChange / priorViews` only when both windows are complete and the prior total is above zero. A zero prior total leaves the percentage null. A negative change is valid.

The source classification is fixed to `agent=user`, `access=all-access` and `granularity=daily`. These are Wikimedia's classifications of page requests. **Pageviews are not unique people, search volume, purchasing intent, sales or a causal explanation of a news event.** Human traffic classification is heuristic and does not guarantee every request came from a person.

Article spelling and case remain exact; spaces are represented as underscores. An article URL must use the selected project and the `/wiki/` path. Its fragment is ignored. Requests go only to `wikimedia.org`; the Actor does not visit the article or follow API redirects. Wikipedia redirects, moves, alternate spellings and language editions are not merged. A missing or mismatched title is a source error, not a zero-attention result.

## Output fields

| Fields | Meaning |
| --- | --- |
| `articleId`, `article`, `project`, `articleUrl` | Stable project/title identity and public article link. |
| `dailySeries` | Fourteen UTC dates with integer views or null for an absent date, plus `available`. |
| `currentWindow`, `priorWindow` | Inclusive dates, expected and observed day counts, missing dates, complete total and observed partial sum. |
| `currentViews`, `priorViews` | Complete seven-day totals; null when that window has missing dates. |
| `viewChange`, `percentChange`, `percentChangeBasis` | Deterministic adjacent-week calculation and why a percentage may be unavailable. |
| `coverageComplete`, `missingDates` | Whether every requested day was returned. An absent day is never filled with zero. |
| `observedAt`, `sourceUrl`, `sourceName`, `dataLicense` | Collection time, exact API request and attribution. |
| `comparisonStatus`, `changedFields`, `previous`, `contentHash` | Optional comparison with the last saved observation. |

A response with some observed dates may produce a useful partial row. Its incomplete window totals and percentage remain null, the run is marked partial, and it does not replace saved history. An empty, invalid, wrong-identity or refused response produces diagnostics in SUMMARY and the report, with no fabricated dataset row. If all sources fail, the run fails. A legitimate unchanged history repeat can succeed with zero rows.

## Saved observation history

The adjacent-week calculation is available on the first run. `comparePrevious` additionally compares the current observation with the last complete row saved for this article in the same history scope. `onlyChanges` enables comparison and skips unchanged observations. The first history run establishes a baseline only after rows are confirmed saved.

Use the same `snapshotName`, project, article list and date mode. An explicit fixed end date creates a separate scope; rolling mode keeps one scope as its boundaries advance. Changed rolling boundaries count as a changed observation. Use one writer per history scope: the store checks for a changed baseline before committing but does not provide an atomic cross-run lock. Missing articles never imply deletion. Failed writes, incomplete windows and rejected charge-limit rows never advance history.

## Three examples

### OpenAI
```json
{"articles":["OpenAI"],"maxResults":1}
```

### Exact article URL
```json
{"articles":["https://en.wikipedia.org/wiki/YouTube"],"maxResults":1}
```

### Explicit project
```json
{"articles":["TikTok"],"project":"en.wikipedia.org","maxResults":1}
```

To examine source revisions for a fixed historical window, add `endDate`, `comparePrevious: true` and a stable `snapshotName`; add `onlyChanges: true` for later polls.

## Limits and pricing

Base pricing is **$0.001 per saved article observation**, including its daily series, plus **$0.00005 per run start**. Reports, diagnostics and skipped unchanged observations create no dataset rows. Apify platform charges can still apply. Review actual pricing before use.

At most ten articles and ten saved rows are permitted. Requests are sequential, limited to 256 KiB and fifteen seconds each, with one short retry only for HTTP 502/503/504 when time remains. There is no fallback after refusal, authentication, proxy routing or redirect following. The own deadline defaults to 120 seconds and is shortened by the platform deadline minus 25 seconds; collection reserves another five seconds for output. Cloud storage requests have a five-second timeout and no automatic retry. Result, charge or deadline limits leave explicit unreached-source diagnostics.

## Source and attribution

Data: [Wikimedia Analytics API](https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/), available under [CC0 and the API access policy](https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/documentation/access-policy.html). The Actor identifies itself with a contact User-Agent and uses sequential requests. See [pageview definitions](https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/concepts/page-views.html) and [the official comparison tutorial](https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/tutorials/compare-page-metrics.html).

This Actor is provided by Mayd It and is not affiliated with Wikimedia. Report a source change or question through the Actor Issues tab or **bmay@mayd-it.com**, including the run ID and article URL. Do not send credentials. No claim of comprehensive audience coverage, source uptime or customer demand is made.