How to Merge LinkedIn Jobs and Your Application Tracker in One Spreadsheet

1. Start with your own application records

Keep an unchanged copy of your current application list before you merge anything. Use an official account export if it supplies the records you need. Otherwise, copy a small set manually from your own records and receipts.

LinkedIn provides a route to request your own personal data. Its help page says that it supplies only your own data, and only the categories that apply to your account. This evidence does not establish that a complete private Job Tracker export is available. Check what your account actually supplies. LinkedIn personal-data help, checked October 25, 2026; complete Job Tracker export not established.

For each application, record the employer, role, available job link, application date, and supporting receipt. A receipt can be your submission confirmation or an employer message. If the date is missing, leave it missing. Do not enter zero or use the date when you copied the record.

Give each separate application an application ID. An ID is a stable label that identifies one record. Keep the same application ID as that application gains more events. A second application to a different opening needs a different application ID, even when the employer and title match.

A saved job is not an application. A draft is not proof of submission. If you cannot confirm that you submitted an application, record that uncertainty. Do not turn every saved job into an applied status.

2. Collect a small public job sample

Use a checked public export if you already have one. Otherwise, the LinkedIn Jobs Scraper, public contract checked October 25, 2026; no paid run tested accepts known job IDs or job URLs. An Actor is a hosted program that collects data. This Actor supplies public listing facts for the method below.

The supplied small input is:

{
  "fetchJobDetails": true,
  "jobIds": ["4251746246"],
  "maxItems": 1,
  "saveOnlyUniqueItems": true
}

Replace the sample job ID with one known job ID or job URL from your own list. Keep the ID inside quotation marks. The supplied input was checked against the public input schema, which defines accepted settings. No paid collection run was made for this guide. Running it is a proposed reader action.

`maxItems` limits the number of saved listings across the collection inputs. Here, the limit is one listing. `fetchJobDetails` requests full descriptions and details when available. It does not guarantee that every field will be present. `saveOnlyUniqueItems` removes repeated job listings within a run. Your spreadsheet still needs its own rule for later imports.

A Task is a saved input preset for an Actor. The public LinkedIn Jobs to Google Sheets Task, checked October 25, 2026; public presence only, saved input and runtime not tested is another starting point. Inspect its saved settings and replace sample values before use. Its name does not establish that it merges personal applications or preserves your event history.

3. Build the Jobs table around checked identity

Create a job key from the platform and the source job ID. A key is the value used to connect matching records. Store both parts as text. Never match two blank IDs, and never use title and employer alone as proof of identity.

The job tracking guide explains why stable platform and job IDs matter across collections. Apply that identity rule before this merge. Notice delivery remains a separate task.

Use these columns in Jobs. The final two rows describe fields that you maintain yourself.

The current public Actor contract documents these source fields. They describe listings, rather than your private application history. Optional values can be missing. Public default build 0.2.26, checked October 25, 2026; static contract inspection, no paid run.

Keep the raw output unchanged. Before adding rows, check for missing IDs and repeated keys. Hold a row with no usable ID for review. Do not give unrelated rows a shared key such as “Unknown.”

4. Create the Application Events table

Keep personal actions in Application Events. Add one row for each supported event. Applying, interviewing, receiving a rejection, withdrawing, and receiving an offer are personal events. They are not public job fields.

An application ID must repeat when one application has several events. A submission and a later interview for the same application share one application ID. Their event IDs must differ.

An ID error occurs when you assign the same application ID to two different applications. Repeated application IDs are therefore not, by themselves, duplicate errors. Check what each ID identifies. Check event IDs separately: each event ID must identify one event only.

Keep receipts under your control. The public collection method does not need your private messages. Store a reference in the spreadsheet when that is enough to find the evidence later.

5. Match applications and leave uncertain keys empty

A join connects rows through equal keys. For this method, join an application to Jobs only after you verify the job identity.

Use these checks for each application:

1. Look for the original LinkedIn job URL or job ID in your application record.
2. Check that the ID belongs to the expected employer and role.
3. Confirm that the same platform and ID exist in Jobs.
4. Enter the checked job key and record the match evidence.
5. If the evidence does not settle the match, leave the job key empty and set the match state to unresolved.

An employer career-page URL may need further evidence before you connect it to a LinkedIn listing. Similar titles and employer names are useful clues. They do not prove that two records describe the same opening. A repost with a different ID also needs review.

Keep unresolved applications in the current view. A missing match does not erase an application that you know you submitted. It means that its connection to a public job row remains unverified.

Apply a confirmed match consistently to the events for that application. Keep the original personal export and your match decision. If later evidence changes the match, record the correction and its reason. Do not silently attach the application to another opening.

6. Write a rule for the current application status

The Current View should show one row per application ID. Build it from Application Events, then add public job facts where a checked key exists. This keeps applications visible even when they have no matched public listing.

Write down how events produce a current status. A small manual tracker can use this proposed rule:

1. Use supported events for the same application ID.
2. Order them by the event date, using a time when you have one.
3. Use the latest event that clearly establishes a status.
4. Send conflicting, undated, or tied events for manual review when their order changes the result.
5. Record any later reopening explicitly instead of assuming that a new note cancels a rejection or withdrawal.

A confirmed submission can support Applied. A supported interview event can support Interview. A rejection, withdrawal, or offer can support its corresponding status. A note about a job page supports none of those personal states.

Keep the event date separate from the recorded date. Entering an old rejection today does not make today the rejection date. An unknown event date stays unknown until you can support it.

Show the application ID, current status, supporting event, checked job key, match state, available job facts, and latest source check. Use an explanation such as “date unknown” in the view when helpful. Do not store that explanation as a date.

7. Import later listings without replacing personal history

An import brings new rows into the spreadsheet. Restrict a public job import to Jobs. Match an existing job key before updating its public facts. Add a new key as a new job row. Do not create an application event merely because a listing arrived again.

Before importing, save a copy of the spreadsheet and the raw source output. Review repeated keys and unexpected changes. Keep the previous observation when changed terms could affect your decision. The public terms comparison guide explains how to compare saved listing text without treating collection time as employer edit time.

Use separate handling for these cases:

A listing disappearing from search does not establish rejection, hiring, or closure. Your last successful source check and your application status answer different questions.

Job selection also remains separate. Use the job fit shortlist guide before deciding which roles deserve application work. This merge method preserves decisions already supported by your records; it does not score your CV or submit applications.

8. Work through one example and check the totals

This worked example is original fiction. All job labels, applications, dates, receipts, and events below are invented. They are not Actor output or employer findings. All dates are in October 2026.

A public import contains five rows with five distinct checked keys:

The personal list contains three applications. Two have checked LinkedIn identities. The third has only an employer-page receipt, with no supported LinkedIn match.

The events table contains four rows:

“Blank in spreadsheet” is a display explanation for this article. Leave that actual spreadsheet cell empty. Do not enter the phrase, “Unresolved,” or another shared placeholder as the stored key. The separate match-state column holds Unresolved.

Application A001 correctly appears twice because it has two events. E001 and E004 remain separate events. The application is still counted once.

The resulting current view is:

Check the arithmetic with clear units:

• Public import: 5 job rows representing 5 unique job keys.
• Personal list: 3 distinct application IDs representing 3 applications.
• Event history: 3 submission events + 1 interview event = 4 event rows.
• Match totals: 2 matched applications + 1 unresolved application = 3 applications.
• Connected public keys: 2 keys. Unconnected public keys: 5 − 2 = 3 keys.

The three unconnected job keys have no matched application in this example. That does not establish anything about records outside this personal list. These are record counts, not counts of people or vacancies across the market.

Now import the same five public rows again. Jobs should still contain five unique keys. Application Events should still contain four event rows. The current view should still contain three applications with the same statuses and match states.

Next, suppose a later batch omits F102. Keep its October 3 observation unless you obtain a newer check. A002 remains Applied under the stated rule. The missing listing adds no rejection event.

Before accepting the spreadsheet, check that every nonempty application key exists in Jobs. Check that no unresolved application has a placeholder key. Check that event IDs are unique and that repeated application IDs belong to the same application. Finally, compare the personal dates, receipts, notes, and statuses before and after the repeated import.