Every competitive intelligence vendor markets their product as "real-time." The term appears in almost every CI platform's homepage headline. It is used to describe tools with crawl cycles ranging from 30 minutes to 72 hours.
"Real-time" has become a marketing claim, not a technical specification.
This article defines what real-time actually means in the context of CI, why the distinction matters practically, and how to evaluate whether a tool's crawl cadence is actually fast enough to be useful for your team's decision windows.
Summary: In CI contexts, "real-time" should mean that signals are available faster than a human action cycle. For competitive pricing intelligence, that means sub-60-minute detection. For hiring and content signals, same-day is acceptable. Tools claiming "real-time" with 24-hour crawl cycles do not meet this standard for time-sensitive decisions. The 4-hour window after a competitor pricing change goes live, before their own sales team has been briefed, is the most concrete illustration of why crawl frequency is a strategic variable, not a feature checkbox.
Defining “Real-Time” as a Functional Specification, Not a Marketing Claim
Real-time means different things in different contexts. In financial markets, real-time means millisecond-level data feeds. In customer support, real-time means immediate notification when a ticket opens. In competitive intelligence, real-time has no industry-standard definition, which is why vendors apply it to products with wildly different actual capabilities.
A functional definition for CI purposes: a signal is "real-time" if it is available to a decision-maker before the window in which acting on it is still strategically meaningful.
That window varies by signal type.
Decision windows by signal type
Pricing changes: The relevant window is measured in hours. A competitor price drop that affects your active deals needs to reach your sales team the same day it occurs, ideally before a scheduled call. A 24-hour crawl cycle fails this requirement.
Product feature launches: The relevant window is 24-48 hours. Your PMM needs to update battlecards before the next sales cycle where the feature becomes a competitive talking point. A 24-hour crawl cycle is marginal; 3-hour is better.
Positioning changes (homepage messaging, tagline): The relevant window is 1-3 days. Same-day detection is ideal, but a next-day signal is still actionable for updating internal positioning docs before the change propagates to a competitor's outbound sales motion.
Hiring signals: The relevant window is 1-2 weeks. A new job posting signals investment direction, but this is a lagging indicator of decisions already made. Weekly monitoring is sufficient.
Blog/content publication: No real-time requirement. These do not affect sales decisions within the same day.
The problem with most "real-time CI" tools is that they apply a single crawl cadence to all page types. A 24-hour crawl cycle is labeled "real-time" even though it fails the functional test for pricing and product signal detection.
The 4-Hour Window: A Concrete Competitive Scenario
This is the scenario that best illustrates why crawl frequency is a strategic variable.
Your competitor changes their pricing at 6pm on a Tuesday. They push the change live quietly, with no announcement.
Here is what happens over the next 24 hours:
6:00pm: Change goes live on their pricing page.
6:30pm: Metrivant detects the change. The signal is classified as pricing_reduction. You receive an alert.
7:00pm: Their internal Slack announcement goes to the sales team.
8:00pm: Their sales team briefs are updated.
9:00am (next morning): Their reps walk into calls with the new pricing brief.
If you received the signal at 6:30pm, you had the option to update your own team brief before their reps were even briefed. If your crawl cycle was 24 hours, you found out at 6:00pm the next day. By then, their rep has already used the new pricing in a call with your prospect.
That 12-16 hour gap, from when the change goes live to when you know about it, is the difference between a proactive competitive response and a reactive catch-up.
The 4-hour window specifically refers to the typical gap between when a SaaS company pushes a pricing change and when their own sales team receives a briefing. In that window, you can know about the change before their reps do. That opportunity only exists if your detection cadence is sub-30-minute, not 24-hour.
How a CI Detection Pipeline Actually Works
Understanding why some tools are faster than others requires understanding what happens between "competitor changes a page" and "you receive an actionable signal."
Step 1 is the crawl. A system fetches the current HTML of a monitored page. Crawl frequency is set per page type. This is the variable that determines how quickly a change can be detected.
Step 2 is extraction. The raw HTML is parsed to isolate the content that matters. Navigation menus, cookie banners, ad scripts, session tokens, and dynamic page elements all introduce noise into a raw HTML comparison. A good extraction layer strips these before the diff runs.
Step 3 is the diff. The extracted content from the current crawl is compared against the stored baseline from the previous crawl. The diff identifies exactly what text changed, what was added, and what was removed.
Step 4 is classification. The diff is interpreted by the classification layer. Is this a pricing change? A feature addition? A messaging shift? Classification separates signal from noise and assigns a signal type with a confidence score.
Step 5 is implication and action. The classified signal is resolved into a strategic movement type, and one recommended action is generated for the team.
Most general-purpose website monitoring tools stop at step 3. They detect that something changed but do not attempt to classify or interpret it. CI-specific platforms run the full pipeline.
The technical discussion of Metrivant's implementation of this pipeline is available in the 8-stage detection pipeline article. The concept of a fully inspectable evidence chain, where every signal traces to a verifiable page diff, is covered in the evidence chain guide.
Why “Real-Time” as a Marketing Term Is Often Misleading
Several patterns explain how vendors misuse the "real-time" label:
Best-case crawl frequency, not guaranteed frequency. Some vendors advertise "real-time" but only achieve sub-hour crawls on specific plan tiers or specific page types. The default configuration may be 24-hour monitoring with "real-time upgrades" as a premium feature.
Real-time aggregation of non-real-time sources. A platform might aggregate data from multiple sources in real time, but if those sources are news APIs, third-party crawlers, or social listening feeds with their own latency, the real-time label describes the aggregation layer, not the underlying data freshness.
Real-time delivery of stale data. An instant push notification about a competitor website change is not real-time if the crawl that detected the change ran 18 hours ago.
How to evaluate this honestly: Ask any CI vendor the following specific questions.
- What is the crawl frequency for pricing pages specifically?
- What is the crawl frequency for homepage and feature pages?
- Is crawl frequency fixed by plan, or configurable?
- What is the median time between a page change and an alert arriving in your inbox?
If a vendor cannot answer these questions with specific numbers, the "real-time" claim is a marketing position, not a technical specification.
Real-Time Monitoring in Practice: Metrivant’s Cadence
Metrivant's crawl schedule is calibrated to the decision windows described above:
- Pricing pages and changelog pages: every 30 minutes
- Homepage and feature pages: every 3 hours
- Blog and careers pages: every 30 minutes (blog as low-priority signal, careers as investment direction signal)
The 30-minute cycle for pricing pages is matched to the practical decision window: if a competitor changes their pricing at any point during the business day, the signal reaches your radar the same day with enough lead time for a response before the next morning's calls.
This frequency is available on all Metrivant plans, starting at $9/month. It is not a premium add-on.
For context on how this compares to the broader CI market, the State of Competitive Intelligence 2026 report covers how SaaS teams are tracking competitors and what monitoring cadences are actually in use.
Setting Up Real-Time Monitoring: What You Actually Need
For a team implementing real-time CI for the first time, the practical setup is simpler than the vendor landscape makes it appear.
Define your signal types by priority. Pricing changes and feature launches need sub-hour detection. Positioning changes and hiring signals can be same-day. Separate these tiers before selecting tooling.
Map your competitors to page types. For 5-10 competitors, identify the specific URLs for pricing page, features page, and homepage. This 15-30 URL list is your core monitoring scope.
Set crawl frequency by page type, not by competitor. Your highest-priority competitors do not need a different crawl frequency. All pricing pages need the same high-frequency treatment.
Define what an actionable signal looks like before you start receiving alerts. This prevents false positive fatigue. An actionable signal from a pricing page includes: what specific text changed, what type of change it was, and what the recommended team action is.
For a full workflow guide, see how to monitor competitors automatically.
To start real-time competitor monitoring with 30-minute crawl cycles on pricing and feature pages, visit metrivant.com/trial.
First-Hand Detection: The Mercury Real-Time Window
In March 2026, Metrivant's monitoring cluster for Mercury (fintech competitor tracking) detected simultaneous changes on Mercury's pricing page and product features page. The detection window was within one crawl cycle (30 minutes) of the change going live.
The classified signal included: before/after text excerpts from both pages, a feature_launch classification on the features change, a positioning_shift classification on the pricing page change, and a combined strategic implication of product_expansion. One recommended action was generated.
A team monitoring Mercury with a 24-hour crawl tool would have detected this change the following day. In a competitive deal context, that 24-hour gap is the difference between updating your battlecard before the rep walks into a call and updating it after the loss debrief.
Ready to see competitor moves in real time?
Frequently Asked Questions
What does "real-time" mean for competitive intelligence tools?
A functional definition: signals are available to a decision-maker before the window in which acting on them is still strategically meaningful. For pricing intelligence, this means sub-60-minute detection. Tools claiming "real-time" with 24-hour crawl cycles do not meet this standard for time-sensitive competitive situations.
How often should a CI tool crawl competitor pricing pages?
Every 30 minutes is the appropriate standard for pricing pages. This ensures a pricing change detected at any point during the business day reaches your team the same day, before the competitor's own sales team has been briefed through their standard channels.
What is the 4-hour window in competitive intelligence?
The 4-hour window is the typical gap between when a SaaS competitor pushes a pricing or product change live and when their internal sales team is briefed on it. With sub-30-minute CI monitoring, you can know about a competitor change before their own reps do. This window only exists if your crawl frequency is fast enough to detect the change within those 4 hours.
Can I get real-time CI alerts without an enterprise CI platform?
Yes. Metrivant provides 30-minute crawl cycles on pricing and changelog pages starting at $9/month. Enterprise platforms like Klue and Crayon also provide rapid detection but cost $15,000-$40,000+ per year. Real-time monitoring does not require enterprise pricing.
How is real-time CI different from social listening?
Social listening tracks brand mentions, sentiment, and content on social platforms, typically with hours to same-day latency. Real-time CI monitors competitor websites directly, detecting changes to pricing pages, feature pages, and messaging that do not appear in social feeds and are not tracked by social listening tools.