Athlete Spotlight

Tag: positive mentions

  • The Athlete Weekly AI Report: What Changed and What To Do

    The weekly AI report is one branded email an athlete gets every week that covers both halves of their online presence: what people said about them, and how their site is doing. It answers a simple question in plain language: what changed this week, and what should you do next. Where we have a live connection to real data, the report shows real numbers. Where we do not, it says “not yet connected” instead of inventing one.

    This is the deliverable behind the marketed promise of ongoing value. It is not a vanity dashboard of follower counts. It is built on the MAA framework (Metrics, Analysis, Action): real metrics week over week, a short honest analysis that names the weakest area, and up to three concrete actions, the first of which always targets that weakest area. This article is the standard that report is built to.

    What the weekly AI report is

    The report is the “Perform” stage of the Content Factory made systematic for one athlete. It runs weekly, reads only real data, and is generated as a file first; sending is consent-gated and idempotent, so an athlete never gets a duplicate and never gets a report for a week we did not actually measure.

    It has two halves, and both are honest about their edges. The mentions half is fully live. The site half reports every signal we can collect for free, and clearly labels every signal we cannot yet reach.

    Half one: what people said about you

    This half is the mentions digest, and it is live today. Each week it surfaces:

    • New mentions this week: organic positive mentions of the athlete found across the platforms we sweep.
    • The ad-ready spotlight: the single best quote, the kind an athlete could actually put on their site or in an ad, chosen for marketability, not just positive sentiment.
    • A game plan: what to do with the week’s mentions.
    • One-click action buttons: add a mention to the site, post it to LinkedIn, or turn it into an ad.

    This half runs on the Positive Mentions System, built by Cam Hazzard and developed with Dennis Yu. Only genuinely usable, positive mentions ever reach the report; criticism is never shown to the athlete.

    Half two: your site this week (MAA)

    This half is a Metrics, Analysis, Action block about the athlete’s website, built entirely from free, no-billing signals. Every signal is independently optional: if one cannot be collected, the report says so rather than blocking or guessing.

    Metrics (real numbers only, week over week where a prior snapshot exists)

    • Site status: up or down, the actual HTTP status code, and response time in milliseconds. An HTTP 403 from bot protection is reported as a 403, not as “down.” A network failure on our side is retried once and then reported as “check inconclusive this week,” never as a confirmed outage.
    • Uptime over the last 7 days: from a free UptimeRobot account, when the site is added as a monitor.
    • Speed score out of 100, plus LCP seconds and CLS: from Google PageSpeed Insights (mobile).
    • SSL certificate: days until renewal, from a direct TLS handshake.
    • Search basics: whether the homepage has a title tag and JSON-LD structured data present.

    Deltas name the actual prior-check date (“up from 151 ms on the 25th”), never a vague “last week.” The snapshot that drives next week’s comparison is saved only on runs that actually send, so the report always compares against the last report the athlete really received.

    Analysis (one short paragraph)

    A single rule-based paragraph that calls out the weakest area (the MAA rule: the analysis must name the weakest metric, not list what we did), names any week-over-week movement, and says “not yet connected” for anything we could not collect. It never invents a number.

    Action (up to three items)

    The first action always targets the weakest signal. The priority order, as built, is: site down or server error first, then SSL expiring or no HTTPS, then a slow response or HTTP errors, then an uptime slip, then speed and Core Web Vitals, then search basics. If uptime is not connected, an action suggests connecting it.

    What is honest to say today, and what is not

    The whole value of this report is that an athlete can trust it. So the standard draws a hard line.

    Live today (real, in the report): uptime, speed score, Core Web Vitals (LCP and CLS), SSL health, search basics, and week-over-week movement on all of them, plus everything the mentions digest already does. The single honest one-line description is: “A weekly AI report on your site and your mentions: what changed and what to do next.”

    Not connected yet (we do not claim it):

    • Google Search Console data: the queries you rank for, clicks, impressions, and average position. This needs the owner’s OAuth consent per site; there is no free keyless path. The planned next step is a Search Console connector added as another optional signal, so this becomes a real part of the report once an athlete connects it.
    • Site analytics: visitors, sessions, and traffic sources. Same reason: it needs the owner’s connection.
    • Rankings movement and follower counts: not collected here, so never claimed here.
    • Any week we did not measure: the report only compares against snapshots that actually exist.

    The conversion: what the report aims actions at

    The MAA Action section is strongest when it measures a real business result, not vanity metrics. For a business, that result is a lead or a sale. For an athlete, the “sale” is fuzzier: a sponsor inquiry, a training-program purchase, a recruiting contact.

    We recommend tracking contact events, sponsor and recruiter inquiries through the Connect page, as the first conversion. The Connect page already carries the athlete’s contact path, so treating a contact event as the conversion gives the weekly report one concrete, ownable business number to trend and to aim actions at, instead of follower counts. It is the smallest honest conversion we can measure without new plumbing.

    The right conversion can differ by athlete and goal. A recruit’s conversion is a coach’s contact; a creator’s conversion may be a sponsor reply or a program sale. We set it per athlete when the site goes live. Until it is set, the report measures site health and mentions, and the conversion line is noted as pending.

    How an athlete turns it on

    The report is opt-in per athlete and off by default, so no one is emailed without consent. Turning it on is two settings on the athlete’s config: the site URL to report on, and the report switch. Without both, the digest is byte-identical to the mentions-only version, with no new output and no network calls. A safe preview path renders the full report to a file without ever sending it, so we can check a report before an athlete sees it.

    Sending itself stays behind the same consent gate as every client email: it goes out only when the athlete has consented and the cadence window is due, it skips weeks with nothing new, and it honors any unsubscribe unconditionally. Nothing in the report auto-publishes anywhere.

    Real examples

    The report runs on the shared Positive Mentions engine that has been exercised across multiple subjects. The site-health half was built and tested against theathletespotlight.com itself and the lighthouse, camhazzard.com, using the free signals above. As athletes are onboarded and opted in, each week’s report for that athlete becomes a data point, and the build of the report is itself documented in three meta articles (how the site-health section was built, how mentions were connected to athlete sites, and how the tooling was kept in sync), each with the real free-API numbers behind it. Those meta articles link back to this standard.

    Related frameworks

    Get started

    The full breakdown of what is included, the weekly AI report among it, lives on the Athlete Spotlight package page. When you are ready, get started for $30 per month and the weekly report starts once your site is live. Parents are welcome to check out on an athlete’s behalf.

    Third-party validation

    The report only uses independent, verifiable sources: Google PageSpeed Insights for speed and Core Web Vitals, a direct TLS handshake for SSL, and UptimeRobot for uptime. Because it reads real signals and refuses to invent numbers, every figure in it can be checked against the source that produced it. The MAA structure it follows is the same measurement framework BlitzMetrics uses across client reporting.

  • How I Connected Positive Mentions to Athlete Sites

    Two systems, one athlete. That is the whole idea. My Positive Mentions System, built by Cam Hazzard and developed with Dennis Yu, finds and scores what people say about someone online. The Athlete Spotlight site factory builds their website. For weeks they ran side by side without talking to each other, which meant the best quotes about an athlete sat in a database while their proof page waited for someone to copy and paste.

    So I wired them together, once, the safe way. This is how positive mentions now flow into an athlete’s website, read-only, human-gated, with zero copy and paste. It is the retention loop behind an Athlete Spotlight site, and it is built so the site tooling can never touch, break, or publish anything on its own.

    What I connected, and why positive mentions matter

    The assignment: make an athlete’s proof section refresh from the mentions knowledge base automatically, without ever letting automation publish, and without letting the site tooling anywhere near production data it could break. The sources were the production mentions engine (a permanent local database), the site factory’s template kit, and a wiring contract I wrote first.

    The deliverable was two small bridge scripts, pma_feed.py (286 lines) and onboard_map.py (154 lines), shipped with the site factory on 2026-07-02. The goal category is the retention loop: a proof page that stays current on its own is the reason an athlete keeps their site, and positive mentions are the raw material.

    How the loop runs, per athlete

    In steady state, the loop is five steps and it repeats every week.

    1. Intake once. A paying athlete’s intake form drives everything. If they opted in, onboard_map.py converts the intake into the mentions engine’s signup payload. One form, two systems, zero re-typing.
    2. Onboard once (human gate 1). A person pipes that payload into the engine’s front door, because it creates the subject and enables the consent-gated weekly digest. Never automation.
    3. Weekly sweeps (automatic). The engine’s existing scheduler collects mentions across YouTube, Reddit, news, and podcasts, scores them with the marketability rubric, and exports. The factory adds nothing here.
    4. Refresh the proof feed. pma_feed.py pulls the current ad-ready quotes into the athlete’s site package: a machine-readable feed plus a website-ready testimonials block, marked DRAFT in its own header.
    5. Review and publish (human gates 3 and 4). A person reads every quote, verifies attribution at the source URL, trims platform openers, then pushes the reviewed block to the live page through a logged-in session.

    Four human gates total, written into the contract as a table: onboarding consent, site-package review, quote review, and the live publish. Nothing in the loop auto-publishes, auto-emails, or writes to the mentions database.

    The calls I’d defend

    Read-only at the database level, not by promise. The bridge opens the mentions database with SQLite’s read-only mode. It cannot write, create, or migrate the database even if I ship a bug. The factory reads production; it never touches it.

    Only usable rows leave the database. The filter is the same marketability-over-sentiment rule the digest and the activation tools use. One gate, shared everywhere. “Fire episode!” is data; it is never a deliverable. The research pile and hidden rows never reach an athlete-facing surface.

    A synthetic pilot that can’t leak. The pipeline test athlete is fictional, so a fixture flag loads a clearly synthetic feed and never touches the database at all, and the onboarding script refuses fixtures outright. The fake athlete can never be onboarded into the real engine. I would rather the tooling be paranoid than fast.

    DRAFT stamped into the output itself. The testimonials block carries a DRAFT header comment, so even the file tells you it has not passed review yet. The verify-before-publish rule applies before any top-tier quote goes live.

    What it cost, honestly

    Honest label: no token receipt exists for this build (the metrics extractor is still an open gap), so these are documented estimates.

    TaskAgent time (est.)Human time (est.)Agent cost (est.)Human cost (est.)
    Wiring contract plus 2 bridge scripts (440 lines) plus fixture and tests~2 hours of session time2 to 3 days for a developerlow single-digit dollars in tokens$560 to $840 at $35/hr
    Per-athlete proof refresh, ongoingseconds per run30 to 60 min of manual quote hunting, weekly~$0 (keyless, local)$17 to $35 per week at $35/hr

    The ongoing row is the real product. The one-time build is cheap; the compounding save is weekly, per athlete, forever.

    What the agent did, and what a human owns

    Autonomous: converting intake to the onboarding payload, pulling ad-ready quotes, rendering the feed and the website block, restyling cards to the site’s design tokens, and scrubbing em dashes by construction.

    Human required: onboarding consent (gate 1), reviewing the site package (gate 2), verifying every quote’s attribution at its source URL (gate 3), and pushing the block live through a logged-in browser session (gate 4). Also profile photos: real ones, re-hosted, never hotlinked.

    What the agent read

    Read: the mentions engine’s usable-row predicate and database layout, the testimonial card shape I adapted, the template kit’s proof pattern, and the intake schema. Written: the wiring contract, the two bridge scripts, the fixture feed, and builder tests. Tokens: not measured (see the cost section). Voice profile: applied to this write-up, not needed for the scripts.

    How it scores against our own gate

    This article ran through the same 18-step gate we use on client work. Passing now: first sentence under 10 words, zero banned words, zero em dashes, contractions throughout, real numbers with estimates labeled, and the canonical parent linked (the Positive Mentions System). Still needs a human: the featured image (a screenshot of the rendered proof section is the obvious pick), Cam’s fact pass, and a live link check. Showing that list is the point of a meta article.

    See it live, and get started

    The proof loop lives inside every Athlete Spotlight website, and the mentions half of the weekly AI report runs on the same engine. This is one of three meta articles on that build; a companion covers how the report’s site-health half was built. The whole thing operationalizes the Perform stage of the Content Factory.

    When you are ready, get started for $30 per month and your proof page starts refreshing from real, verified mentions once your site is live.

    Dunking and business are the same game. You do the reps where nobody is watching (the sweeps, the scoring, the gates), so the highlight, a coach’s quote on your site, verified and current, looks effortless.

    Built by Cam Hazzard, developed with Dennis Yu.