Anyone Using GPT-Dot to Track Competitors on a Regular Basis?

Ai Tools
1

I’ve tried asking GPT-Dot to compare competitor pricing and feature pages, then checking the results against my notes. I’m doing this for a small product team. I need to catch actual changes, not get another general overview of what each competitor sells. So far, keeping a consistent baseline has taken more manual work than I expected.

Is anyone using GPT-Dot to track competitors on a regular basis? Are you reusing the same prompts and page URLs each time, or feeding it saved copies to compare? How do you check that a reported change wasn’t just something it missed on the previous pass?

2

I’d expect to keep a small evidence archive even with automated checks. For your setup, I’d reuse the prompts and page addresses, but feed it dated copies for the comparison. I wouldn’t use its previous summary as the baseline. The saved page should be the thing you check against when a change looks suspicious.

I’d make the comparison prompt pretty strict: “For each proposed change, quote the old text and new text, identify the section, and give both capture dates. If the earlier capture doesn’t contain enough evidence, label it unverified.” For an alleged addition, ask it to show the corresponding section from the old copy, rather than accept “I didn’t find this before.” That gives you a way to separate a site change from a missed detail.

The rule I’d be most stubborn about is not replacing a good baseline with an incomplete capture. Keep a separate “couldn’t check” status, and hold the currency, billing toggle, and logged-in state constant when saving pricing pages. I’d rather get a short report with an unresolved check than have a missing section quietly treated as a removed feature.

3

Don’t judge it only by whether the changes it reports are correct. @espritlibre’s saved-copy approach gives you something to test with: deliberately change a usage limit or move a feature between plans, then see whether the comparison catches it. I’d want that check before trusting a “nothing changed” report.

4

You can waste a lot of review time comparing different versions of a page rather than actual updates. The saved-copy test makes sense, but I’d set some ground rules for the captures too: same currency, billing toggle, and logged-in status each time. Otherwise, an annual price compared with a monthly price could become your next urgent alert. For a small team, I’d keep the report boring: old text, new text, page, and capture dates. If those conditions don’t match, flag the comparison as inconclusive instead of sending it through as a competitor change.

5

A changed page is not necessarily a changed offer; the saved-copy method provides grounds for determining what has changed but I would like to draw a firm distinction between ‘the competitor has modified this text’ and ‘the competitor has changed what customers are offered.’ For a product team, the second type of change is what is important and I would prefer a non-trivial defense of the second type of change.

For example, if a competitor changes a call to action from ‘Start your free trial’ to ‘Contact sales,’ I’d want to record that as a change to the conversion process, but that does not necessarily mean that they have stopped offering trials. It would be preferable for the report to state a definite change to the offering. Same with removing a feature from a comparison table but not from the description of another plan.

That’s where I’d extend @crypto_beacon442’s test. Give the comparison some edits that should not count as an offer change: a rewritten benefit statement, a reordered feature list, or a shorter label that means the same thing. Catching a planted limit change is useful. So is leaving harmless copy edits out of the urgent queue. Otherwise you’re still doing the interpretation yourself, only now you have a longer report to read first.

For the standard run, I would request two separate fields: “What changed on the page?” and “What does this establish about the offer?” with the latter one being “unclear.” If the pricing page and the supporting page contradict each other, leave that contradiction there; do not attempt to interpret which version is more plausible, just leave it as is. It may be useful to flag a potentially conflicting argument for manual review instead, but not present it as an established change to the product offering.

I would still want to see the minor edits left in the results, just separated from the main body of changes. It may be important to the team to note a change in messaging, but it should not be presented as a change on par with an entitlement. The report I would find most useful to receive and act upon would look something like “Signup wording changed. Trial availability is unresolved. Check before updating the sales comparison.” It is less conclusive and probably less exciting than a competitor’s thorough analysis, but it leaves fewer assumptions hanging and does not present them as actual facts.

6

Expect some review work every week, but you shouldn’t have to review the same change every week. For a recurring setup, I’d keep a small change log outside the chat so each run can distinguish a newly detected change from something your team has already handled.

That’s a separate job from comparing saved pages. The comparison produces candidates. The change log records what happened to those candidates: awaiting review, accepted, dismissed, or unresolved. A spreadsheet would be enough to start. Give each item a stable ID, attach its evidence, and record when it was first detected and last checked. Don’t use the generated summary as the identifier, since a different sentence describing the same edit shouldn’t create a new task.

For example, suppose a competitor moves an integration into a more expensive plan. You review the evidence and update your internal comparison. On the next run, that integration is still in the more expensive plan. That’s the current state, not another change. If a help page later catches up with the pricing page, I’d attach that evidence to the existing item rather than automatically sending a second alert. It may resolve a question you left open, but it doesn’t necessarily represent another product decision.

I’d push back slightly on putting all the minor edits in the regular results. Keep them available, yes. Put them in front of the team every time, no. Once someone has dismissed a wording change, it should stay out of the review queue unless new evidence changes the interpretation. An unresolved item should remain visible without repeatedly presenting itself as new.

The matching needs a little care. Grouping everything by competitor and feature would be too broad: a later reversal or another limit adjustment deserves its own entry. I’d match using the affected plan, attribute, and old-to-new transition, then flag uncertain matches rather than letting the model silently merge them. The model can propose that two findings belong together. Your stored record should control whether an item is considered handled.

My acceptance test would be to rerun an unchanged pair of captures after marking its findings reviewed. The system should retain the history and produce no fresh review tasks. Then introduce a further edit to the same feature and check that it surfaces. That tests whether you have a recurring monitoring workflow, rather than a comparison prompt you’ll have to keep cleaning up after.

7

A competitor editing their existing plan page is a somewhat different monitoring problem from launching a new plan on a new page. Your saved comparisons may catch the former while missing the latter entirely, a hole that should be watched closely in a monitoring routine that’s based on using the same page addresses over again. ‘Nothing changed on these pages’ is a helpful reminder, but not a complete answer to ‘nothing changed with this competitor’.

I’d split the work into a frequent check of known pages and a less frequent check of whether the watch list still covers what you care about. For that second pass, start from the competitor’s navigation and look for newly linked plans, add-ons, or product pages. Any newly found page needs a first capture, not an automatic “new offering” alert. It might have existed for months without being on your list. @static_gadget’s change log would benefit from keeping “new to our monitoring” separate from “changed since our last capture.” For a small team, I’d rather check a narrow list consistently and revisit its coverage occasionally than quietly treat that list as the whole business.

8

If the competitor is running A/B tests or serving different content by region, a lot of this workflow starts reporting ghosts before you ever reach the change log. You capture the page Tuesday, you capture it Thursday, the text is different, and nobody on their side touched a thing. You just got bucketed into a different experiment, or your scraper hit a datacenter IP that gets the US pricing instead of whatever a real visitor in your market sees. That’s not a competitor change. That’s noise dressed up as signal.

So before trusting any of the strict-prompt stuff @espritlibre laid out, I’d pin down how deterministic the page even is. Hit it a few times from the same setup and see if the capture is stable without any real edit. If it isn’t, you don’t have a baseline problem, you have a sampling problem, and no amount of old-text-new-text quoting fixes that.

The matching-by-transition idea from @static_gadget is the strongest thing in this thread, and I’d lean on it even harder, because stable IDs are also how you survive experiment flapping. If a plan toggles between two variants across runs, a transition-keyed log lets you see it’s bouncing rather than firing a new alert every cycle. A page-diff tool alone can’t tell ‘they changed their mind’ from ‘they’re testing both.’ Your record can.

Where I’d push back a little: everyone’s treating the saved copy as ground truth. It’s ground truth for what that capture saw, not for what the competitor published. If the capture was a cached or experimental version, your archive is just a very confident record of the wrong thing. Worth stamping each capture with enough context to spot that later, not only the date.

Honestly, for a small team I’d worry less about catching every wording tweak and more about whether your captures are even capturing the same reality twice. Get that right first. The clever comparison prompt is wasted on unstable inputs.

9

Don’t assume the thing GPT-Dot pulled is even the pricing page a human sees. Half the time the actual numbers come from a script or a geo widget that a bare fetch never runs, so you end up diffing the fallback markup against another fallback and calling it stable. @retrothread_77 is right that you have a sampling problem before you have a baseline problem, but I’d go one step further: check whether the price is in the captured text at all, or whether you’re just archiving the page scaffolding. If the figure you care about lives in a rendered component, no strict old-text-new-text prompt will save you, because the text was never there to compare. Pull it twice, eyeball that the real prices actually show up, then worry about change logs and transitions.