The short answer
First establish that the two files represent the same account, category and comparable collection scope. Compare exact nonblank keys only after resolving duplicates. Report present-in-both, earlier-only and later-only records. An earlier-only row establishes a file difference; it does not by itself prove who removed a connection or why.
What you’ll take away
- A snapshot difference is not a dated event log.
- Names are unsuitable as automatic person-merge keys.
- Preserve unmatched and ambiguous records for review.
Choose a question the files can answer
A useful narrow question is which profile references occur in each delivered file. A much stronger question is which people ended a relationship during a month. Two snapshots cannot generally establish the latter: missing categories, collection gaps and identifier changes can produce differences without that event being observed.
Write your question and comparison unit first. Keep account-data categories separate. Connections, imported contacts and followed members have different meanings; merging them creates apparent changes that are actually changes of population. A larger combined row count is not evidence of a larger network.
Create a source receipt for each snapshot
Record the private source reference, requested category, request/download time, any stated coverage and the exact file identity. Distinguish an archive’s delivery date from a date represented by its contents. If the platform does not expose an exact collection instant, say that instead of inventing midnight precision.
Inspect headings and record counts independently. If one source is filtered, truncated or from another account, stop the direct change claim. You can still describe the files, but label the scope difference. A hash helps identify the bytes later; it cannot make incomparable collections comparable.
Choose and audit the comparison key
Prefer a documented stable identifier when the source actually supplies one. A profile reference can serve as a declared comparison key in a limited exercise, but a URL is not a promise of permanent person identity. Do not silently lowercase or remove URL components and assume the result is verified.
Check blank keys and repeated keys in each file before comparing membership. Keep a separate queue for unresolved records. Two people called Mira Demo remain distinct when their references differ. If a reference changed between snapshots, an earlier-only and a later-only record may be the same person, but that needs additional evidence.
- Confirm comparable source scope.
- Select the exact key and record its meaning.
- Separate blank and repeated keys.
- Compute intersections and one-sided key sets.
- Inspect candidates before writing any relationship explanation.
Follow the complete two-file exercise
The ZIP contains snapshot-before.csv and snapshot-after.csv, each with two fictional rows and an explicit observed_at value. The declared key is profile_reference. The earlier file contains references ending /a and /b; the later one contains /a and /c. The two Mira Demo rows in the earlier file deliberately have different references.
The result is one shared key, one earlier-only key and one later-only key. Both files have two rows. Net row-count change is zero even though membership differs. The included JSON records this exact limited result. It contains no LinkedIn event, verified relationship termination or actual person.
| Set | Fictional key | Supported statement |
|---|---|---|
| Both | https://example.invalid/record/a | Present in both example files |
| Earlier only | https://example.invalid/record/b | Absent from the later example file |
| Later only | https://example.invalid/record/c | Absent from the earlier example file |
Keep explanation separate from observation
Use “not present in the later file” until there is evidence for a stronger conclusion. Do not send a message accusing a person of disconnecting because their row disappeared. A private archive comparison is an observation about available records, not a notification from the platform explaining an individual’s action.
For a public recap, the number of new rows is not automatically the number of new supporters, leads or customers. If your intended claim requires those concepts, collect appropriate permitted evidence separately. Otherwise publish the narrower file-based statement with its scope and uncertainty.
Save a reviewable comparison instead of a merged audience
Keep the two original files unchanged and save a small result with source identities, declared key, unresolved counts and set totals. If you manually resolve a candidate, record the evidence and decision without deleting its earlier status. That makes a later correction possible.
The browser inspector on the related import guide checks one file at a time; it does not claim to compare two private archives. The worked snapshot JSON is a transparent fictional membership example. A production comparison needs your actual authorized sources and a review of their limitations.
Sources & product references
Product details reflect the publication date. External features and interfaces may change.
