Study Public Reactions to a Competitor Price Change

1. Establish the price event from an official source

A public researcher describes checking pricing pages manually, taking screenshots, and trying to remember what changed last week. This points to a practical need: keep dated evidence instead of relying on memory. That public question provides context. It does not measure demand for this method. See the public research question, published August 1, 2026; retrieved October 25, 2026; one public account of a research problem.

Find an official announcement, pricing notice, or other dated statement from the competitor. Save its address and the exact passage that describes the change. Record when you observed it.

Keep these dates separate:

• Announcement date: when the company said the change would happen.
• Effective date: when the stated change takes effect.
• Observation time: when you saved or checked the source.

Record which plan, region, billing period, and customer group the notice covers. Keep each item unknown if the source does not state it. A change for new subscriptions does not establish the same change for existing subscriptions.

If the notice gives several effective dates, choose one stated group for the comparison. Otherwise, separate the groups. One before-and-after boundary cannot describe several different start dates accurately.

A current pricing page alone may not establish the previous price or the date of a change. If you did not retain the older page, do not invent its contents. Record that gap. This guide supplies no official competitor price announcement, so you must provide that source before applying the method to a real event.

2. Define the comparison before collecting posts

Create a price-event cohort sheet. Here, a cohort means the group of posts that meet your stated timing and event rules. It does not mean a group of verified customers.

Write one research question. For example: “What reactions appear in selected public posts before and after this plan change takes effect?” Keep that question separate from questions about sales, retention, or market share.

Use equal window lengths where possible. Write the exact start and end of each window. Use one time zone, and state how you handle a date without a time. Make the boundary precise enough that one post cannot enter both windows.

Keep announcement timing visible. A window before the effective date can already contain reactions to the announcement. It is not necessarily a period before people knew about the change. A post published after the effective date also does not prove that its writer saw the announcement or paid the new price.

Save these study-level fields:

Keep this sheet stable during collection. If you change a rule, record why and review both windows under the revised rule.

3. Use the Actor to find candidate posts

An Actor is a hosted data collection program. The Reddit Search Scraper Actor provides candidate public posts for manual review. It does not establish the official price event or complete this comparison for you.

The supplied evidence checked public default build 2.0.6 on October 25, 2026. Its declared input structure supports the small input below. A static check confirmed that the input follows that structure. No collection was run for this brief. The check does not prove live availability, result quality, or complete coverage. See the default-build evidence, checked October 25, 2026; declared fields and static validation only.

{"maxResults":3,"query":"software price increase","sort":"relevance","time":"all"}

Use this as a proposed starting input:

1. Replace `query` with the competitor’s name and terms that identify the price event. Keep each exact query in your sheet.
2. Keep `maxResults` at 3 for the first collection check. This is a requested result limit, not a promise of three usable posts.
3. Inspect the returned records before expanding the search. A small check helps you assess the records; it does not establish enough evidence for a conclusion.
4. Keep `sort` and `time` consistent across comparable searches. Record any change.

The sample uses `sort` set to `relevance` and `time` set to `all`. It does not specify the two event windows. Assign posts to those windows from their publication dates during review. A relevance-sorted result set is not a balanced sample of both periods.

A Task is a saved input preset for an Actor. The Reddit Brand Mention Snapshot Task, checked October 25, 2026; page presence only, saved settings unverified is a possible starting point. The public page contained Task ID `cKrwlcryUm7yGmgkG`. Its current saved input and runtime behavior were not verified. Do not describe the proposed JSON above as that Task’s saved input.

Record the same intended community scope for both windows. Check the communities of the returned posts. If you collect more queries later, apply them to both periods and retain their settings.

4. Save source fields and your review fields separately

One discovered post is a source record. It is not one verified buyer, one affected subscription, or a complete reply discussion.

Retain the declared source fields used in this method:

These are declared fields, not a guarantee that every record contains every useful value. Check the actual values. An empty or null date is unknown. It is not an early date. Missing text does not mean that the writer had no reaction.

Keep publication time separate from observation time. A post first collected after the effective date may have been published before it. Do not assign its window from `observedAt` when its publication date is missing.

Add your own review columns beside the source fields:

The Actor does not supply these research judgments. You add them after reading the evidence.

Public posts and official public notices are different from owner-only records. Subscription records, account notices, and cancellation records require authorized access. This public search workflow does not supply them. Keep any authorized private records separate from the public-source sheet and its claims.

5. Check event relevance before coding reactions

Publication timing alone is not enough. A post after the change may discuss an older increase, another plan, or a general complaint about cost.

Use your written inclusion rule. Require enough context to connect the text to the documented event. A product name plus “expensive” may leave that connection unresolved. Open the public source when the saved text does not provide enough context. Keep the row pending if you still cannot decide.

For each included post, record the stated reaction without strengthening it. “I plan to cancel” expresses an intention. It does not establish a completed cancellation. “This will cost our team more” is a public statement, not checked billing evidence. A question about the price can remain a question.

A code is a short label that you assign to text under a written rule. Define your reaction codes before summarizing them. Keep the supporting passage beside each code. Allow an unclear state when the text does not support a firm label.

Retain stated conditions. A complaint about annual billing differs from a complaint about the monthly price. An existing subscriber may face different terms from a new subscriber. Do not fill in an unstated plan or customer status.

If a post discusses another product, retain that context without turning this event study into a switching-rate analysis. The separate guide on researching stated product choices and switching conditions covers that question. A price reaction alone does not establish a switch or its reason.

6. Resolve repetition and collection failures

Keep repeated observations of the same `postId` linked. Do not count the same post again because another query found it. Retain its collection history so you can explain where it came from.

Different post IDs can contain the same quoted complaint. Keep those sources, but mark the shared quotation. Repeated words are not proof of separate customer experiences. Do not merge different posts solely because they use similar language.

Check these failure states before comparison:

No returned posts does not establish zero public reactions. Likewise, no observed cancellation statement does not establish zero cancellations. Missing evidence and an observed zero answer different questions.

7. Compare the selected posts and test other explanations

Count included posts separately for each window. State the unit every time. Six posts means six posts. It does not mean six people or six affected customers.

For any fraction, name the denominator, which is the group used as the total. A theme count should use only the posts eligible for that comparison. Keep uncertain timing, unrelated events, and unavailable text visible outside the applicable total.

You can compare the themes and conditions that appear in each period. Keep counts beside the passages that support them. If one period has more collected posts, do not treat the raw difference as a change in customer sentiment or discussion volume.

Check whether the interpretation depends heavily on one discussion. The guide on checking whether one Reddit thread controls a result explains that separate count-unit problem. Use it when needed without converting this post comparison into a customer estimate.

Record other possible explanations. Check whether your sources mention another product change, an outage, a promotion, a billing correction, or another event near the price change. These are review questions, not claims that such events occurred.

Also retain two unknowns: whether each writer saw the announcement, and whether the new price applied to that writer. Equal windows do not remove those unknowns. A before-and-after pattern supports a description of the selected discussion. It does not prove cause.

8. Work through an original fictional example

Everything in this example is original fiction. It is not an Actor run, a customer result, or an observed company finding.

A fictional official announcement is dated October 3. The price change takes effect October 10. The researcher compares October 3–9 with October 10–16, using the same queries and community scope. Each window has seven days.

Both windows follow the announcement. “Before” means before the October 10 effective date. It does not mean before awareness of the change.

The researcher has nine candidate posts:

The arithmetic uses posts as its unit:

• 3 before posts + 4 after posts + 2 uncertain-date posts = 9 candidate posts.
• 9 candidate posts − 2 uncertain-date posts = 7 dated posts.
• 7 dated posts − 1 older-event post = 6 comparable event-relevant posts.
• The final comparison contains 3 before posts and 3 after posts.

The older-event post remains excluded even though its publication date falls in the after window. The two uncertain-date posts remain outside the timed groups. Do not assign them from their collection dates.

Compare the stated reactions and conditions in the six eligible posts. This example supplies no reaction text, so it supports no theme totals or change in sentiment. It teaches the inclusion arithmetic only.

The denominator for this fictional comparison is six dated, event-relevant posts. The excluded three remain visible in the disposition record. Six eligible posts do not measure six affected customers. No churn estimate follows from them.