What I Actually Track When I Create Content
The system I built doesn't try to manage every possible thing a creator might want to track. It tracks seven fields and nothing else. Publishing date, platform, content type, status, keyword used, estimated hours, and whether it was ever cross-posted. That's it. Anything more and the tracker becomes slower to use than whatever it was supposed to replace. I started tracking content after I lost a client because I couldn't answer a simple question: how many pieces did I actually publish last quarter versus what I promised? I had spreadsheets with eighty columns and zero useful data. The tracker I ended up building took me about three weekends to set up and another two to realize I needed to stop adding features. The core method is a shared Google Sheet or Airtable base with the seven fields I mentioned. Every piece of content you publish gets one row. That row is updated as it moves from ideation through editing to publishing. Status changes are logged in the same row, not in a separate column for each milestone. You can see the full lifecycle of any piece at a glance.
Here's the thing most people miss: the status field should use relative terms, not absolute ones. Instead of "Draft," "Editing," "Published," use "Not started," "In progress," "Completed," and "Repurposed." The reason is simple. A piece stuck in "Draft" for six months looks different from a piece in "Draft" for three days. Both are called Draft in most systems. They aren't the same problem. Relative status labels surface urgency better. I hit a real edge case with this about a year in. I was cross-posting the same video across YouTube, LinkedIn, and TikTok within the same week. The tracker showed three separate rows for essentially one piece of work. This inflated my output numbers by about 40% in that reporting period, which meant my actual content velocity was much lower than the dashboard suggested. I fixed it by adding a Content ID column. The same source material shares one ID. The tracker then shows one published piece with three platform tags instead of three separate entries. This took me about ten minutes to implement and immediately made my monthly reports honest again. The estimated hours field is where the tracker actually pays for itself. I track this per piece and sum it at the end of each week. Over six months, this data told me something I didn't expect. My "quick" carousel posts were averaging four hours each because I wasn't counting research and caption writing. The tracker forced me to account for work I was doing in my head and ignoring on paper. After seeing the real numbers, I dropped those formats entirely and shifted to long-form written content, which ran about ninety minutes per piece and converted better for my goals.
The keyword used field sounds minor but it connects directly to what actually performs. I review this column monthly alongside any analytics data I pull. The pattern it reveals is consistent: the keywords driving traffic aren't the ones I think they are. The tracker makes it trivial to see which search terms actually generated views versus which ones I just assumed would work. This alone justified the entire system for me. There are real limitations to this approach. The tracker only works if you actually log every piece before or immediately after publishing. If you batch-log ten items on the last day of the month, the data loses its usefulness. I've seen this happen repeatedly. The second limitation is that it doesn't capture creative quality. A well-performing post and a poor one look identical in the tracker until you connect external analytics. I use a separate lightweight tab for performance scores if I need that detail, but most weeks I don't bother. For people who need more than this, Airtable offers a template structure that mirrors the same seven-field logic with some automation. For anyone who wants to avoid paid tools entirely, the Google Sheets version does the job without subscription costs. You can build the whole thing in about twenty minutes by setting up column headers, enabling data validation on the status field to prevent typos, and applying conditional formatting that colors rows based on how many days they've been marked In progress. Anything older than fourteen days turns yellow. Older than thirty turns red. This color coding alone reduces the time I spend scanning the tracker from maybe five minutes down to thirty seconds per review session.
Get the Full Details
The repurposed flag is the last field and the one I initially resisted. I thought it was redundant. It isn't. Knowing which pieces I've already pushed through multiple platforms prevents me from accidentally re-scheduling the same content or missing an opportunity to extract a quote or statistic from something that already proved useful. It also feeds directly into the efficiency numbers I care about when pricing future projects. If you want to start, pick one sheet or base, copy the seven fields exactly, and commit to using it for thirty days before judging whether it works. That window is long enough to catch the rhythm of logging and short enough that abandoning it mid-project doesn't create much wasted data. Most systems fail because people treat them as complete solutions from day one instead of rough drafts that improve through actual use.
