--- name: ecommerce_store_prospecting description: Qualifying online stores as sales prospects: verify the platform from two fingerprints, count the catalog and read prices from public feeds where the platform serves them, read app and review and traffic signals as banded proxies, score stores against a sweet spot set before the run, and build a qualified list with a contact path and a source per row. Use when someone sells to store owners and asks which stores to reach out to, wants a list of Shopify or WooCommerce stores in a niche, needs stores qualified or tiered, or wants to check whether a store is big enough and live enough to be worth outreach. For running your own store use ecommerce_seller_ops, for general B2B account research use lead_intelligence, for timing outreach to a company event use buying_signal_prospecting, for local businesses use local_lead_prospecting. --- # Ecommerce Store Prospecting ## Purpose Sell to stores and you face a specific problem. There are huge numbers of online stores, most of them are too small, too new, paused, or too large for a given offer, and almost none of them publish the numbers that would settle it. Revenue and order volume are not public. What is public is a set of traces a store leaves on its own site: its platform, its catalog, its prices, the tools whose scripts show up on its pages, its reviews, and whether anything on it has changed lately. This skill turns those traces into a qualified list. Every row is a verified operating store, measured the same way, scored against a sweet spot written before the run, with the deciding fact named and a public contact path attached. Three worked evaluations are in references/worked-evaluations.md. Signal definitions, fingerprints, and limits are in references/signal-sources.md. Two limits shape the whole method. First, a proxy is not a measurement: a traffic tier, a review count, and a product count can rank stores against each other, and none of them tells you what a store earns. Second, a gap you infer from a missing tool trace is a hypothesis to test in conversation, never a fact to state in a pitch. ## Workflow ### 1. Write the store brief before you look at any store - State the offer in one sentence and who at a store would own it: owner, ecommerce manager, marketing lead, or support lead. - Define the target store: platform or platforms, product category, geography or market if it matters, and language if your product needs it. - Set the sweet spot in numbers and write it down: product count range, a liveness test (something visibly changed inside a window you pick), and a demand test (reviews on an independent platform, a traffic tier, or both). - Write the disqualifiers the same day: marketplace-only sellers with no store of their own, stores in a category your product cannot serve, stores that are already customers, dropship shells with no brand or contact path if your offer needs a real operator, and enterprises whose buying process your motion cannot reach. Route those last ones to a named account list instead of scoring them as bad stores. - Pick the one traffic estimator and the one review source for the run, if you use them. Mixing sources inside one list makes the tiers incomparable. Thresholds set after you have seen the stores are decoration. Set them now, from your own close and churn history if you have it, and label the first run's thresholds as a starting guess you will revisit after one cycle. ### 2. Build a raw list from discovery sources that you can name Use the sources in references/signal-sources.md, section 5, in this order of effort: - A store database or technology list filtered by platform, category, app presence or absence, geography, and traffic tier. - Search operators for indexed stores, such as site:myshopify.com plus a niche or place term. - Published app reviews in your category, where the review shows the merchant store name and country. - Niche directories, roundups, and supplier stockist pages. - Your own inbound, trials, and past customers, from your own records. Record the discovery source and the date for every store. A store you cannot say how you found is a store you cannot defend later, and source quality is the first thing to cut when reply rates disappoint. ### 3. Verify the platform with two signals - Check the live store, not just the listing that produced it. Use the fingerprints in references/signal-sources.md, section 1. - Record the platform only when two independent signals agree, for example a platform CDN host in the page source plus a platform URL pattern, or a technology lookup plus a checkout trace you saw yourself. - Watch the two known traps: a hosted platform buy button embedded on another platform's site, and a headless storefront that hides its traces until checkout. - If you cannot verify, record unknown and keep the store. The scorer caps an unverified store at INVESTIGATE, which is the right place for it until a person confirms the platform. ### 4. Measure the catalog and the prices On Shopify, start with the public catalog feed, as detailed in references/signal-sources.md, section 2: - Page through /products.json at up to 250 products per page. Compute product_count, median first-variant price in the store currency, the share of variants on sale, and the share unavailable. Note gift cards or add-on lines you removed and why. - Read the currency from the store itself. Write it next to every price. Prices are strings in the feed and availability is a yes or no per variant, never a stock count. - If the feed is off, blocked, or returns 404 on a headless store, count from the sitemap and shop index pages, sample two category pages to confirm the count, and label it an estimate with its method. On other platforms, count product URLs in the sitemap or shop index the same way and sample to confirm. The point is a count you made on a date, with a method you can repeat, not a count a database asserted. Then check liveness: newest product update, a current seasonal collection, a dated post, or a recent review. Nothing visible in over a year means treat the store as possibly paused and require a human check before outreach. ### 5. Read app, review, and traffic signals as bands - Group visible app and pixel traces by job: email, reviews, subscriptions, support, loyalty, search and merchandising, analytics and ads. Presence is a trace on a date, not a paid contract. Absence sets gap_match only when the missing job matches your offer and the store's products make that job plausible, for example a refillable product with no subscription trace. - Count reviews and read the rating on the independent platform itself where you can, not only on a badge on the store. Record platform, count, rating, and date. - Record traffic as a tier (none, low, med, high) from the one estimator chosen in step 1, against thresholds set before the run. Estimators build their numbers from panels and partner data and do not measure the store, and they are weakest on small and new stores. Never put an estimated visit count in a brief as if it were the store's traffic, and never use a missing estimate as proof of no traffic. Full reading rules are in references/signal-sources.md, sections 3 and 4. ### 6. Score every store and work the bands in order Put the measured stores in a CSV and run the scorer: ```bash python3 ~/workspace/skills/ecommerce-store-prospecting/bin/store_score.py \ --stores stores.csv --out scored.csv ``` A worked input file ships at references/example-stores.csv. It covers a qualified store, a large store routed out of the sweet spot, a tiny store that is too early, a store capped by an unverified platform, and a fit rejection. The scorer is this skill's starting heuristic, not a research finding. Fit is a hard gate and scores zero as REJECT_NO_FIT. Verified catalog depth, category match, review band, traffic tier, app traces, a gap hypothesis, liveness, and a contact path add points. Bands: QUALIFIED at 60 or more, INVESTIGATE at 35 to 59 or whenever the platform is unverified, TOO_EARLY below that where the store shows no buyers yet, OUT_OF_SWEET_SPOT for a large high traffic store that needs a named account approach, and REJECT_NO_FIT when fit fails. Work QUALIFIED first. For INVESTIGATE, do the one check the notes name, usually platform verification or a contact path, and rescore. Leave TOO_EARLY on a dated recheck list instead of pitching early and burning the store. After each cycle, compare reply and meeting rates by band and by discovery source, and adjust the weights or the sweet spot where your own data says they are wrong. ### 7. Attach a contact path and pass the outreach gate - Find the contact path on the store itself first: contact and about pages, a wholesale or stockist page, and the business name in the footer. Confirm a named person on a second public business source before using the name. - Use a business address or form the store published for business contact. A guessed email pattern is a guess. Label it as unverified if it goes on the list at all, and never present it as found. - Check the list against suppression and current customers before anything is sent. An opt-out or a prior no ends contact. - Outreach follows the law where the recipient is. In the US, the FTC CAN-SPAM guide covers all commercial email with no business to business exception: accurate headers, a subject line that matches the content, clear identification as an ad, a valid physical postal address, a clear opt-out, and honoring opt-outs within 10 business days. In the UK and EU, a business contact's details are still personal data and the legitimate interests route needs a documented assessment before use. Apply the strictest rule that fits the recipient and get a real legal view for a program, not a single campaign. - In the message itself, use one public fact you verified, state the gap as a question, and stop. Never claim you know a store's revenue, orders, traffic, or tool spend. You do not, and the owner knows you do not. ## Output Contract Deliver, for each run: - A scored store list (CSV from the scorer) with store, domain, platform, score, band, and the notes that decided the band. - The brief behind the run: offer, target store, sweet spot numbers, disqualifiers, and the single traffic and review sources used, with dates. - For every QUALIFIED store, a short brief: platform and the two signals that verified it, catalog count with its method and date, median price with its currency, review count and traffic tier with their sources, the app traces grouped by job, the gap hypothesis worded as a hypothesis, and the public contact path with its source. - For every INVESTIGATE store, the single check that would move it up or cut it. - A recheck list for TOO_EARLY stores with a recheck date, and a routed list for OUT_OF_SWEET_SPOT stores saying where they go instead. - A calibration note at the end of a cycle: reply and meeting rates by band and discovery source, and any sweet spot or weight change you are making because of them. ## Operating Rules - No revenue, order, or traffic claims about a store from public signals. Counts you made and tiers from a named estimator, labeled as such, are the whole vocabulary. - Two signals or the platform is unknown. One scanner result is a lead for a check, not a verification. - A missing tool trace is a hypothesis, worded as a question in every brief and message. Never tell a store it lacks a tool, a process, or buyers. - A badge on a store's own site is not a review count. Check the independent platform where you can. - Respect site terms, robots rules, and rate limits when you read public pages and feeds. Work at a pace a careful human would, stop on a 429, and use an official API or a licensed database where bulk work needs one. - Personal data stays inside the rules for the recipient's place. Business contact details are still personal data in the UK and EU, and a public page is a source for a business fact, not permission for bulk scraping or bulk messaging. - Cut honestly. A short list of verified stores with contact paths beats a long list of asserted ones, and the report says which stores were cut and why. - If a signal proves wrong on a live check, log it against the source that produced it. A source that keeps producing dead or mislabeled stores gets dropped, not worked around.