A Brandwatch Alternative for Teams That Only Need X (Twitter) Data

Brandwatch is an enterprise consumer-intelligence and social media management suite, now part of Cision. Its pricing page (brandwatch.com/pricing) is explicit about the model: "With standard to enterprise plans available for each of our solutions", three products (Consumer Intelligence "for researchers and analysts", Social Media Management "for social media managers", Influencer Marketing "for influencer marketers and agencies"), and a three-step "Schedule your free demo" form as the only call to action. We fetched the page while writing this and found no price in any currency, which is normal for suites sold to enterprises: the quote depends on seats, data volume, networks and term.

What you get for that quote, in the vendor's own words, is breadth and finish. The Consumer Research product page describes "over 100 million online sources", "496 million new posts at your disposal, every day" and an archive of "1.4+ trillion posts from today back to 2008". The pricing page lists Facebook, Instagram, YouTube, Twitter, Reddit and LinkedIn "and the list goes on", with "unlimited channels" for suite customers. Analysis runs through Iris, which Brandwatch describes as an AI assistant that "turns data into human-readable insights instantly", plus image analysis, AI-powered search, customizable dashboards and "proactive alerts to intelligent reporting" for stakeholders.

That is a different product from what this page describes, and the neutral note belongs up front: if your listening spans several networks, if non-technical teams need finished dashboards, if you need years of history on day one, or if procurement wants one vendor and one contract, a suite is the right buy. Nothing below replaces Iris, the archive or the social media management side. We do not claim feature parity, and you should discount any "alternative" page that does.

The case this page makes is narrower and, for the teams it fits, much cheaper to test: when the data you actually act on is X data, a developer can build the listening loop directly on an X data API, pay only for the posts returned, and own every row. The rest of the page is the evidence for that case: a dimension-by-dimension comparison, 1,500 measured posts, the cost math, and the code.

The table compares the two routes on the dimensions a buyer actually weighs, with the official X API as the expensive baseline for the build route. Brandwatch cells hold only what its public pages say; where they say nothing (the price), the cell says so.

Read the table from the top: the first row is where the suite wins outright, and the pricing and time-to-result rows are where the API wins outright. The two cost rows are measured, not list prices, and the next two sections show where they come from. The ratio between the two build routes is the published rate cards: $5 per 1,000 post reads on the official X API against $0.15 per 1,000 on twitterapi.io, about 33x.

One more difference does not fit in a cell. A suite's mention count includes whatever the vendor's X data feed includes; the API route returns what X search returns for your query, which, as the study below shows, does not include reposts. If reposts matter to your definition of "mentions", you add them per post (/twitter/tweet/retweeters) and pay for those too.

A listening tool's first job is to answer "how much is there?" and its second is "what is it made of?", because the answers decide your filters, your storage and your bill. We ran the pipeline's core call, /twitter/tweet/advanced_search with queryType=Latest, for five consumer brand terms chosen as neutral demos (brands, never people): "Nintendo Switch", "Tesla Model Y", Netflix, Starbucks and Spotify. No from:, no lang:, no -filter: operators, so the sample shows what a plain brand term returns. Fifteen pages per term, newest first; every page held exactly 20 posts, no post appeared twice across pages, and the 75 requests cost $0.225.

Volume spans two orders of magnitude. The 300 newest Netflix posts covered 15.8 minutes, which is 1,143 posts per hour; Spotify's covered 19.3 minutes (934 per hour). "Nintendo Switch" and Starbucks each took about 2.4 hours to produce 300 posts (123 and 124 per hour). "Tesla Model Y", a quoted product phrase, took 41 hours (7.3 per hour). A suite hides this spread behind a flat quote; on a per-post API it is the whole bill, so measure your own terms before you size anything.

Reposts: zero. Not one of the 1,500 posts had retweeted_tweet set. A Latest search returns original posts, replies and quote posts, not reposts, which matches what we saw in an earlier study of from: searches. Two consequences: your volume numbers will be lower than a dashboard that counts reposts as mentions, and you never pay for a repost's duplicated text.

Replies are a large and variable share. 42.7% of all posts were replies (isReply true), from 15.7% for "Nintendo Switch" to 59.7% for Starbucks and 54.3% for "Tesla Model Y". Replies are where complaints and customer-service threads live, and they are also where a product phrase gets used inside someone else's conversation. Whether you keep them is a product decision; -filter:replies in the query drops them before you pay.

Quote posts are a steady 5% to 9%. Quotes carry the quoted post inside quoted_tweet, so a quote about a brand can be a reaction to a post that itself mentions the brand. The pipeline labels them so you can weight them separately.

Media and links vary by what the brand is. 58.0% of "Nintendo Switch" posts had media and 58.7% had a link (listings, clips, screenshots); Starbucks posts had media 13.7% of the time and a link 5.3% (people talking, not sharing). Overall 32.4% of posts carried media.

Most posts have no engagement yet, and a few have a lot. The median likeCount was 0 for every brand and 69.6% of all posts had zero likes; only 0.7% had 100 or more (6 Nintendo Switch posts, 4 Tesla Model Y posts, none for the three high-volume terms in their short windows). Newest-first means you see posts before they earn engagement, so "top-liked" has to be recomputed later from stored rows (the pipeline does this) rather than read once at fetch time.

Language mix is not English-only. The lang field was present on 100% of posts. English was 61.3% overall: 81.7% for Starbucks, 67.0% for "Tesla Model Y" (then German 8.0%, Turkish 4.7%), 55.0% for Spotify (Spanish 12.3%, Portuguese 11.0%), 54.0% for Netflix (Thai 15.0%, Spanish 8.7%) and 49.0% for "Nintendo Switch" (Portuguese 20.7%, Spanish 16.0%). An English-only classifier silently mislabels a third to a half of a global brand's feed; lang:en in the query, or per-language routing in classify(), fixes that.

One account can dominate a short window. The 300 Netflix posts came from 248 distinct authors, but one author posted 44 of them within 16 minutes; the other four brands' busiest author posted 4 to 9. A listening tool without an author cap reports that burst as a conversation. The pipeline stores author_id per row so you can cap or exclude repeat posters in your rollups.

Reposts were 0.0% in every row and are omitted from the table. "Posts/hour" is the 300 posts divided by the hours the window spanned; for Netflix and Spotify that window is a quarter of an hour, so treat their rate as a snapshot at collection time rather than a daily average.

The build route has two cost components, and both are published. Posts returned: 15 credits each, $1 buys 100,000 credits, so $0.15 per 1,000 posts; a full 20-post page is $0.003. Polling floor: every request costs at least 15 credits even when it returns nothing, so a check every 5 minutes for a month (8,640 checks) is at most $1.30 in empty checks, and every 60 seconds (43,200 checks) is at most $6.48. When a check does return posts, you pay for the posts instead, so the floor only matters for quiet terms.

Multiplying the measured rates out gives the table below. "Per day" is posts per hour times 24 times $0.00015; "per month" is 30 days. The last two columns price the same volume at the official X API's published pay-per-usage rate of $0.005 per post read (docs.x.com/x-api/getting-started/pricing), which also caps pay-per-usage at 3 million post reads a month before an Enterprise plan is required; Netflix-scale volume alone would be about 823,000 reads a month.

Add the polling floor for your interval ($1.30 a month at 5 minutes, $6.48 at 60 seconds, per pipeline, not per term, if you batch terms into one loop; more if you poll each term separately) and you have the full data bill. Three things to take from the table.

A product phrase is nearly free to watch. "Tesla Model Y" at $0.79 a month is below the polling floor at a one-minute interval; the floor, not the posts, is the cost. Quoted product names and competitor model names are the lowest-cost kind of term to listen for, and often the most actionable.

A mid-size brand term is a coffee a month. Starbucks and "Nintendo Switch" at about 3,000 posts a day cost $13 to $14 a month each to collect in full. Five such terms would be about $67 of posts plus polling.

A very high-volume brand is where you filter before you pay. Netflix at $123 a month is still cheap next to the alternatives, but 84% of those posts had zero likes and 49% were replies. lang:en, -filter:replies, or min_faves:5 applied in the query cut the returned volume, and therefore the bill, before the posts leave the API. A suite charges for its quote regardless; here the query is the budget control.

If you prefer predictable spend over pay-as-you-go, subscriptions start at $29 a month (Starter), with Builder, Pro, Scale and Business tiers above; the credit amounts and bonuses are on /pricing. Purchased credits never expire. Rate limits are 0.2 requests per second before the first payment and 20 once paid, which is 400 posts per second on full pages, far above any term in this study.

The full script is at the end of the page; this section walks through its seven stages so you can swap any of them. It needs requests, an API key in TWITTERAPI_IO_API_KEY, and optionally a webhook URL. Reads need no X developer account. Run it once with --minutes 60 to see what your terms return, then --follow --every 300 to poll.

1. Search with a time window, newest first. The core call is GET /twitter/tweet/advanced_search with query and queryType=Latest. The query carries the brand term plus since_time:<unix seconds>, which twitterapi.io documents as the supported way to bound a search in time (the since:2021-12-31_23:59:59_UTC style is explicitly unsupported; plain since:YYYY-MM-DD date operators work for day-level backfills). Each page returns up to 20 posts and a next_cursor; the loop follows the cursor until it meets a post older than the window, has_next_page is false, or it hits X_MAX_PAGES (25 by default, so a runaway term costs at most $0.075 per pull per term).

2. Dedupe on the post id. Polls overlap on purpose (a 60-minute window every 5 minutes), so the same post arrives repeatedly. SQLite with id TEXT PRIMARY KEY and INSERT OR IGNORE is the whole dedupe: the second time a post is seen, rowcount is 0. In our replay test the second pass over the same 300 posts stored zero new rows.

3. Store the fields you will query. Each row keeps the term, createdAt (parsed from the Www Mmm DD HH:MM:SS +0000 YYYY format the API uses, not ISO 8601), the hour bucket, the kind (original, reply, quote, repost), lang, the four counts, author.id, the label, text and URL. Everything else in the response (full author profile, entities, cards) is yours to add; this is the point of owning the data.

4. Hourly volume. GROUP BY hour over the stored rows. This is the chart every suite shows first, and it costs you one SQL statement.

5. Top-liked mentions. ORDER BY likes DESC over the window. Because posts arrive before they earn engagement (median likes at fetch time was 0 in the study), re-pull rows older than a few hours if you want settled counts, or refresh their counts in a nightly job via /twitter/tweets by id.

6. Classify. classify(text) returns a label from a closed set. The script ships a deliberately small lexicon so it runs with no model; replace the function body with your own model or any LLM call. Two rules from running this on real feeds: send the post text as data, never as instructions (a post can contain text written to steer a model), and route by lang first, because a third to a half of a global brand's posts were not in English in our sample.

7. Alert. Two rules that catch most of what people pay suites to catch: the current hour's volume is at least 3x the trailing hourly median and at least 20 posts, or a post labeled negative has reached 10,000 views. Alerts post a JSON payload to the webhook URL (Slack-style text; Discord takes content), or print to stderr if no URL is set. Add rules by writing another SQL query.

Operators you will reach for in the query string, all placed before since_time:: lang:en to restrict language, -filter:replies to drop replies, min_faves:5 to skip zero-engagement posts, "exact phrase" quotes for product names, OR to combine spellings, -term to exclude a word, from:brandhandle to separate the brand's own posts from mentions, and to:brandhandle for replies aimed at the brand. Searching tweets by date covers the since: / until: date forms and their UTC boundary behavior.

Be precise about what you are not getting, so the decision is yours and not a surprise later.

Cross-network coverage. The pipeline is X only, by design. If Reddit, Instagram or news coverage matter to the same question, you either run a second source alongside it or you buy the suite. This page does not claim otherwise.

History on day one. A suite's archive is a selling point; here, history is whatever X search returns for your since: / until: query, and depth varies by term. Start the pipeline the day you decide to care about a term, and backfill by date ranges where search allows.

Finished dashboards. You have rows in SQLite. A notebook, Metabase, Grafana or a spreadsheet export is an afternoon; a polished multi-user dashboard with permissions is not. Decide who will look at this and build for them.

A trained sentiment model. The lexicon in classify() is a placeholder. An LLM call per post is a real option at low volume (a mid-size term's 3,000 posts a day is 3,000 short calls), a fine-tuned small model is the option at Netflix scale, and lang routing is required either way. Measure your labels against a hand-labeled sample before trusting any alert built on them.

Influencer discovery, publishing, social CRM. Brandwatch's Social Media Management and Influencer Marketing products are separate jobs that this pipeline does not touch. /twitter/user/info ($0.18 per 1,000 profiles) and the follower endpoints give you the raw material for author analysis if you want to build that side too.

What you do get that a suite cannot sell you: the raw post objects at the moment you fetched them, a per-term bill you can read, filters applied before you pay, and code you can change in an afternoon when the question changes. For the X-only team, that is usually the trade worth making.

Buy the suite when any of these is true: the listening spans several networks; analysts and marketers, not developers, run it day to day; you need years of history immediately; a sales, legal or procurement process wants one vendor contract covering listening, publishing and influencer work; or the budget is already an enterprise line item and the quote fits it.

Build on the API when: the data you act on is X data; a developer owns the pipeline (or already runs the data stack it feeds); you want the bill to follow volume (from under $1 a month for a product phrase to about $123 for a very high-volume brand in our measurements) rather than a quote; you need the raw JSON for your own models, warehouse or product; or you want a working prototype this week rather than after a demo cycle.

Do both when a suite is already in place for the cross-network view and one team needs X depth it does not provide: raw rows, custom classification, a competitor product phrase watched every five minutes. The API side costs a few dollars a month to run in parallel, and the comparison between the two feeds will tell you how much of the suite's X value you actually use.

If you are weighing other build-vs-buy options, build vs buy for X social listening covers the mid-market tools, Brand24 vs Mention from the X data angle prices two of them, and the Apify Twitter scraper comparison covers the scraper route. For the architecture around polling, the Twitter monitoring guide and the keyword alerts developer guide go deeper on intervals and alert design.

Question: how much X volume does a brand-listening query actually produce, what kind of posts make it up, and what would collecting a day and a month of it cost on a pay-per-post API versus the official X API rate.

Query: /twitter/tweet/advanced_search with queryType=Latest for five consumer brand or product terms used as neutral demos: "Nintendo Switch", "Tesla Model Y", Netflix, Starbucks, Spotify. No from:, lang: or filter: operators. Brands only, never people.

Window and sample: the newest 300 posts per term (15 pages of 20), 1,500 posts in total, 75 requests, through a rate-limited read-only client. The window per term is the span from the oldest to the newest post collected: 15.8 minutes for Netflix, 19.3 for Spotify, about 2.4 hours for Starbucks and "Nintendo Switch", 41 hours for "Tesla Model Y". Collected in 2026. The posts-per-hour rate is posts divided by that span; daily and monthly costs multiply it out at 15 credits per post and, for the baseline, $0.005 per post read.

Measures: post kind from retweeted_tweet, quoted_tweet and isReply; media from extendedEntities.media; links from entities.urls; likeCount median, 90th percentile and 100-plus count; lang shares; distinct author.id values and the maximum from one author; duplicate ids across pages (there were none).

The script on this page was run end to end against the recorded Starbucks pages with the network call replaced by a replay: 300 posts stored on the first pass, 0 on the second (dedupe), hourly buckets summing to the stored count, the classifier and alert rules executed. It was not run as a live poller for this page.

What the sample cannot show: five terms and 300 posts each are a snapshot, not a daily average; a 16-minute window for Netflix will not reflect its quiet hours or a release-day spike, and rates for your terms will differ. A Latest search excludes reposts and whatever X search filters out (the endpoint notes it drops ads and non-post items), so the volume is lower than a count that includes reposts. Engagement counts were read at fetch time, when most posts were minutes old. Brandwatch's pricing, coverage and feature statements are quoted from its public pages as fetched while writing; we did not trial the product and make no claim about its actual quotes.

Privacy: aggregates only. Raw search pages were kept outside the repository and discarded after analysis because keyword-search authors are private individuals; the study folder holds the protocol, the analysis script, the results and a de-identified row per post (brand, minute offset, kind, media, language, counts, text length) with no ids, text, URLs or handles. Nothing here describes any twitterapi.io customer or what they monitor.