A video player connects to a text card and a timed list. A crossed-out document sits to the right.

A watch event is one recorded viewing action. Two watches of the same video are two events. An archive is a downloaded copy of account data. Your main result should contain one row for each watch event recorded in that archive.

You can add current public video details later. Keep that step separate. Public video details cannot recover missing private watch events.

Define what you need to check

The reader question asks for a “full YouTube watch history.” This creates two different checks: whether your table preserves the exported events, and whether the archive covers the history you expected.

You can compare the table with its source files. You cannot prove complete lifetime coverage from those files alone. One public owner question reports an incomplete Takeout export. That is one reported gap. It does not establish a failure rate or a method that guarantees complete history.

Plan to save three records:

  1. A private note about the requested archive and its contents.
  2. A watch-event table that preserves repeated watches and original times.
  3. An optional public video table, with one selected result per video ID.

An ID is a value that identifies an item. A video ID identifies a video, not a watch event. Keep those two uses separate throughout the method.

Request your archive and record its scope

Use only your own Google account. Open the signed-in Google Takeout page through the official download guide.

Do not rely on a fixed menu path or file name. Inspect the current product choices and included-data choices.

  1. Select the YouTube or account-activity data needed for your watch history.
  2. Record the account and selected data privately.
  3. Record the request date.
  4. Request the archive.
  5. Download every archive part supplied for that request.
  6. Record the archive creation date, file format, and part names.
  7. Keep the original files unchanged.
  8. Open a working copy and confirm that it contains watch events.

Search activity and subscriptions do not establish which videos you watched. Confirm the record type from the actual contents before you count rows.

The selected data defines the requested scope: the account data you asked Google to include. Record the contents actually received as a separate fact. A selected category alone does not prove that the downloaded files contain every expected record.

Keep the archive private. The optional public check needs selected public video IDs or links. It does not need the archive or your account credentials. Downloading your data does not delete the cloud copy. Google’s export scope and limits

Build a table that preserves each watch event

Read the actual field names before you import the files. Do not assume a fixed file structure, date format, or video field.

Create one working row for each source watch event. Keep all original fields. Add references that let you find the event in the unchanged archive.

The fields below are proposed working fields. They are not promised Google export headings.

Build a table that preserves each watch event
Working fieldWhat to saveRule when information is missing
Archive referenceThe archive request or saved-copy referenceInvestigate an unknown source
Source file and event referenceFile name and row or entry locationAdd a reference before further processing
Original activity textExact activity text suppliedLeave missing text empty
Raw event timeExact source timestampDo not substitute another date
Source time zoneZone or offset, if suppliedMark an absent zone unresolved
Normalized event timeA checked common time value, if possibleLeave unset until the time can be resolved
Original video linkExact source link, if presentRetain the event without a link
Checked video IDVideo identity established from the sourceKeep uncertain identity unresolved
Time review stateWhether the time was resolvedPreserve the reason for uncertainty
Public lookup stateNot attempted, matched, or unresolvedKeep this separate from archive coverage

A timestamp is a stored date and time. A normalized time is a second value converted to a common form. Neither should replace the raw source value.

A source reference locates an event in your saved archive. It is not necessarily a stable event ID across different exports. Equal row numbers in two files do not establish equal events.

An absent video link does not erase a recorded watch event. Keep the event and mark its video identity unresolved. Likewise, an empty field means information is missing. It does not mean zero watches.

Resolve times without changing their meaning

Watch time, video publication time, and public lookup time describe different events.

Resolve times without changing their meaning
TimeMeaningCorrect use
Archive event timeWhen the archive records the watch actionOrder or group recorded watches
Video publication timeWhen the video was publishedDescribe the video
Public lookup timeWhen public details were collectedDate the public observation
Archive request or creation timeWhen the export was requested or createdDescribe the archive

Parse a date only when you know its format. Parsing means reading stored text as a date and time. An ambiguous date must remain unresolved until you can establish its meaning.

  1. Keep the raw timestamp unchanged.
  2. Identify the date format from the source.
  3. Identify the time zone or offset, if supplied.
  4. Convert the value only when those facts are known.
  5. Save the converted value beside the raw value.
  6. Record any unresolved time issue.

UTC is Coordinated Universal Time, a common time reference. You may save a normalized UTC value when the source time can be resolved. Do not assign a time zone merely because your computer uses it.

Do not use import time as watch time. Do not use video publication time to fill a missing event time. If you later group watches by day, state the reporting time zone. Resolve time questions before you treat daily totals as checked results.

Keep repeat watches and remove only proven import copies

Two events can share a video ID, title, or date. That does not make them duplicate events.

For example, a morning watch and an evening watch of the same video remain two rows. Removing rows by video ID would lose part of the recorded history.

Deduplication means removing confirmed copies of the same record. Apply it only when you have evidence that your import created those copies. Importing the same unchanged archive twice is a case you can investigate through archive, file, and source-entry references.

  1. Count the imported watch-event rows.
  2. Check whether any archive part was imported twice.
  3. Identify copied source records through their source references.
  4. Remove only the demonstrated extra copies.
  5. Record how many copies you removed and why.
  6. Save the retained event count before adding public details.

Matching video IDs or timestamps alone does not prove that two rows are copies. Overlapping archives need a separate record review. Do not force uncertain matches into one event.

Decide whether you need public video details

You can stop with the checked event table if it answers your question.

Optional metadata can add current titles, channel details, and public counts. Metadata means information about an item. It describes the video; it does not establish another watch event.

The Chronometrica YouTube Metrics Scraper is an Actor, a hosted data collection program. Its documented inputs include known video IDs and video links. It also supports public channel discovery, which is not needed to check this archive.

The Actor reads public video metadata and metrics. Metrics are counts such as public views or likes. It does not read personal watch history or private videos. It does not collect comment text or provide YouTube Studio impressions, click-through rate, or retention.

Prepare a separate list of unique, known public video IDs. This reduces repeated public lookups while preserving every watch event. The transcript corpus guide also separates repeated source appearances from unique video identities. Here, the unique list serves only the optional lookup. Your event table must keep repeated watches.

If you later need a video’s spoken text, use the separate caption extraction guide. Captions do not establish whether or when you watched a video.

Configure the optional public lookup

The youtube-engagement-metrics-tracker Task provides a starting preset. A Task is a saved Actor input preset.

The supplied evidence checked the public Task page and its ID on 25 October 2026. It did not inspect authenticated saved settings or run the Task.

The following small input passed a format check against the supplied public input rules. JSON is a text format for structured data.

json
{
  "maxItems": 1,
  "startUrls": [
    "https://www.youtube.com/watch?v=dQw4w9WgXcQ"
  ]
}
Configure the optional public lookup

The sample link is an input example. It is not a result from this method.

  1. Inspect the Task settings before use.
  2. Replace the whole sample list in `startUrls` with your intended public video IDs or links.
  3. Use direct video inputs for this archive check.
  4. Set `maxItems` to allow the intended public result rows.
  5. Send no private archive files or watch-event rows.
  6. Run a small list that you can inspect in full.
  7. Save the input, output, and lookup time separately.

The shown `maxItems` value limits output to one metric row. Leaving it at one for a larger list can prevent the output from covering that list. Compare the submitted IDs with the results; do not assume that a completed run covered every intended video.

These are proposed reader actions. No private archive was accessed or tested for this guide. No paid Actor run was made. The documented fit supports this optional public check; it does not prove runtime performance.

Attach public results without losing events

Keep the public output in a separate table. Preserve the exact returned values and their status information.

Attach public results without losing events
Actor fieldWhat it records
`inputUrl`Submitted input
`postId`Returned video ID, when present
`postUrl`Returned video link, when present
`title`Current available video title
`publishedAt`Video publication value
`views`, `likes`, `comments`, `remixes`Public counts, when available
`postMetricStatus`Availability and precision of public video counts
`status`Returned result state
`scrapedAt`Public collection time

The `comments` field is a count, not comment text. Missing counts remain unavailable. Preserve `null`, which represents a missing value, rather than replacing it with zero. Keep precision information too; a rounded public count must not become an exact count in your report. Actor output contract

Select at most one public observation per checked video ID for this version of your table. If you make later checks, save them separately and state which observation you use.

A join combines tables through a matching value. Match the selected public result to every event with that checked video ID. Preserve events with no match. For a failed result without a returned ID, retain its submitted input reference and investigate the match.

Check both directions of error:

  1. If the event count falls, check whether unmatched events were removed.
  2. If the event count rises, check whether several public results matched one event.
  3. Confirm that each original event reference remains exactly once.
  4. Confirm that repeated watches still have separate rows.

A failed public lookup does not establish that a video was deleted, made private, region-limited, or temporarily unavailable. Keep the cause unresolved unless separate evidence establishes it.

Worked example: three events and two video IDs

This example is original fiction. The event labels and lookup outcomes are invented for teaching. They are not private archive records or Actor test results.

A fictional archive records video A at 09:00 and 17:00, plus video B at 18:00. This simplified example supplies no date or time zone. Keep those limits visible; do not calculate UTC times from these values.

Worked example: three events and two video IDs
Fictional eventVideo labelRaw timePublic lookup outcome
E1A09:00Metadata available
E2A17:00Metadata available
E3B18:00Metadata unavailable

The event table has three rows. The separate lookup list has two video IDs: A and B. In the fictional check, A returns metadata and B does not.

The arithmetic uses different units:

  • 2 watch events for A + 1 watch event for B = 3 watch events.
  • 1 unique ID for A + 1 unique ID for B = 2 unique video IDs.
  • 1 available metadata result + 1 unavailable metadata result = 2 lookup outcomes.
  • 3 event rows before the join = 3 event rows after the join.

Both A events receive the selected A metadata. B’s 18:00 event remains, with metadata marked unavailable. The failed lookup does not erase the recorded watch.

Report three recorded watch events and two unique video IDs. These counts do not measure unique people. They also do not prove that the archive contains every watch event from that day.

If B’s public view count is missing, keep it missing. Zero public views would be a numerical claim that this fictional lookup does not support.

Check archive coverage and unresolved states

Compare the requested scope with the included files. Where practical, compare selected archive records with the history visible to you in My Activity. Record the account, period, and date of that comparison.

YouTube states that videos watched while history is off do not appear in history. Owners can also delete history manually or use auto-delete. Public video details cannot reconstruct those missing private events. YouTube history controls

Keep different problems separate:

Check archive coverage and unresolved states
Observed stateWhat you can concludeNext check
Expected watch file absentExpected archive content is missingReview selected data and downloaded parts
Time cannot be resolvedEvent time remains uncertainCheck raw format and source zone
Video ID absentEvent lacks a checked lookup identityRetain the event and inspect its source
Known ID not submittedPublic lookup was not attemptedSubmit it only if metadata is needed
Public lookup failedCurrent metadata remains unresolvedPreserve the result without guessing a cause
Expected period has no recordsCoverage is unresolvedCompare archive scope and owner-visible history

An empty period is not proof of zero watches. An old earliest row is not proof of complete history. Successful parsing proves that your process read the files; it does not prove that Google supplied every past event.

Before accepting the table, confirm that all archive parts are accounted for, raw values remain unchanged, time issues remain visible, and every retained source event survives the public join. Report archive gaps separately from lookup failures.

Sources & further reading

By Chronometrica · Updated

Back to top ↑