Add nomadro.live English WordPress stack and audience router
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
eric
@@ -0,0 +1,16 @@
|
||||
<p>A live monitoring toolkit is software that captures stream events in real time so an operator does not have to stare at a single player window. It is not a replacement for the native live studio. It is an operations layer on top of it.</p>
|
||||
<h2>What it actually captures</h2>
|
||||
<p>Useful toolkits record chat, gifts, follows, shares, room joins, and viewer counts as discrete events with timestamps. The point is a structured feed you can filter, alert on, and archive. If a tool only screenshots a dashboard, you cannot reconstruct what happened after the fact.</p>
|
||||
<h2>Who needs one</h2>
|
||||
<p>Solo creators with long sessions, agencies running several rooms at once, and night-shift operators all hit the same limit: human attention. A toolkit exists to make attention scarce and events complete.</p>
|
||||
<h2>Local versus cloud</h2>
|
||||
<p>Local capture keeps session files on your machine. Cloud capture is easier to share across a team but introduces account, latency, and data-residency questions. Pick based on whether your primary risk is losing a laptop or leaking a chat log.</p>
|
||||
<h2>A minimum viable setup</h2>
|
||||
<ul>
|
||||
<li>One reliable event stream per room</li>
|
||||
<li>Alerts for gifts and keyword spikes</li>
|
||||
<li>A session archive you can export</li>
|
||||
<li>A documented restart procedure when the live disconnects</li>
|
||||
</ul>
|
||||
<h2>What it is not</h2>
|
||||
<p>A monitoring toolkit does not grow your audience by itself. It does not bypass platform rules. Treat it as instrumentation for people who already run lives and need fewer missed events.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Gift events are dense, bursty, and easy to miss if you only watch an on-screen ticker. Tracking them as data lets you thank the right people, notice unusual spikes, and review a session without scrubbing a recording.</p>
|
||||
<h2>Capture the fields that matter</h2>
|
||||
<p>At minimum log sender handle, gift name, quantity, diamond or coin value if available, and timestamp. Without value, a “Rose x99” and a high-tier gift look the same in a naive count. Without a handle, you cannot follow up.</p>
|
||||
<h2>Burst handling</h2>
|
||||
<p>Combos arrive faster than a human can type. Debounce on-screen toasts so operators see a summary, but keep the raw events in the archive. Summaries are for the shift. Raw events are for the post-show recap.</p>
|
||||
<h2>High-value thresholds</h2>
|
||||
<p>Define two alert tiers before the show: “acknowledge in chat” and “pause other work and thank on camera.” Numbers differ by creator. The mistake is using one threshold for every room and then ignoring the alerts.</p>
|
||||
<h2>After the live</h2>
|
||||
<p>Export the gift table, sort by value, and mark who already received a public thank-you. Repeat gifters over several nights are a relationship list, not a one-off statistic.</p>
|
||||
<h2>Integrity</h2>
|
||||
<p>Do not invent gift values. If the upstream event omits a field, store it as unknown. Fake precision in recap decks trains teams to distrust the whole pipeline.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Agencies that run several rooms at once fail first on attention allocation, not on software. Multi-channel monitoring only helps if you decide which rooms are primary and which are watch-only.</p>
|
||||
<h2>Primary versus secondary rooms</h2>
|
||||
<p>A primary room gets full chat response and gift acknowledgements. A secondary room gets alerts and a lighter check-in cadence. If every room is primary, none of them are.</p>
|
||||
<h2>Operator load</h2>
|
||||
<p>One operator can usually sustain one primary plus two secondary rooms if alerts are quiet. Four noisy primaries produce missed thanks and delayed moderation. Measure this with a two-hour trial, not a slide deck.</p>
|
||||
<h2>Layout</h2>
|
||||
<p>Put viewer trend and last high-value gift on a single glance row. Chat detail belongs in a selected-room panel, not eight simultaneous scrolling columns. Density that looks impressive in a demo is unusable at 2 a.m.</p>
|
||||
<h2>Handoffs</h2>
|
||||
<p>Write the room list, alert thresholds, and who is on camera into a shift note. Incoming operators should not reverse-engineer the setup from open windows.</p>
|
||||
<h2>Failure isolation</h2>
|
||||
<p>If one room’s connection dies, the other rooms must keep recording. Shared process crashes are the most expensive class of bug in this category. Prefer per-room isolation when you can.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Webhooks turn live events into actions in other systems: a Discord ping, a spreadsheet row, a light on a desk, a CRM note. They are useful when the action is boring and time-sensitive.</p>
|
||||
<h2>Start with one rule</h2>
|
||||
<p>Pick a single event type—high-value gifts is the usual first choice—and send it to one destination you already check. Ten half-working rules are worse than one reliable rule.</p>
|
||||
<h2>Idempotency</h2>
|
||||
<p>Live feeds retry. Your receiver must tolerate duplicate event ids. If the upstream has no id, hash timestamp plus sender plus gift name and drop duplicates inside a short window.</p>
|
||||
<h2>Secrets and exposure</h2>
|
||||
<p>Webhook URLs are credentials. Do not paste them into public docs or client-side code. Rotate them when an operator leaves. Prefer signed payloads if the tool supports them.</p>
|
||||
<h2>Backpressure</h2>
|
||||
<p>A viral minute can fire hundreds of events. Queue on the receiver. Dropping events silently is better than crashing the live monitor process because a chat app rate-limited you.</p>
|
||||
<h2>Test before showtime</h2>
|
||||
<p>Send a synthetic event, confirm the destination, then disable the synthetic source. Debugging webhooks during a paid collab is a self-inflicted outage.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Desktop and Android monitors solve the same event problem with different constraints. Choosing wrong usually means battery death, a blocked port, or a machine that cannot sit in a bag.</p>
|
||||
<h2>When desktop wins</h2>
|
||||
<p>Long sessions, multiple rooms, large charts, and webhook fan-out all prefer a plugged-in Windows machine. Keyboard shortcuts and a second monitor reduce misclicks during gifts.</p>
|
||||
<h2>When Android wins</h2>
|
||||
<p>A phone in a pocket can follow a single room while you are away from the desk. Foreground services and notification channels matter more than chart density. If the OS kills the process, you have no archive.</p>
|
||||
<h2>Battery and radios</h2>
|
||||
<p>Hotspot plus 24/7 capture plus screen-on is a thermal problem. Use a charger, disable unused radios, and test a four-hour run before you trust the device on a real show.</p>
|
||||
<h2>Notification design</h2>
|
||||
<p>Phone alerts should be reserved for thresholds you will actually act on. Desktop can show more toast noise because it is not in your pocket during dinner.</p>
|
||||
<h2>Shared operator habits</h2>
|
||||
<p>Use the same room list, the same gift thresholds, and the same archive naming on both platforms. Tool switching should not require a new mental model every night.</p>
|
||||
@@ -0,0 +1,16 @@
|
||||
<p>A creator ops dashboard is a decision surface, not a wallpaper of charts. If you cannot say what you will do when a number moves, remove the number.</p>
|
||||
<h2>Four tiles that earn their space</h2>
|
||||
<ul>
|
||||
<li>Current viewers versus the session median</li>
|
||||
<li>Gifts in the last five minutes</li>
|
||||
<li>Chat rate versus baseline</li>
|
||||
<li>Connection health (last event age)</li>
|
||||
</ul>
|
||||
<h2>Baselines beat raw counts</h2>
|
||||
<p>2,000 viewers means nothing without the usual range for that creator and timeslot. Compute a rolling median from previous sessions and show deviation, not vanity totals.</p>
|
||||
<h2>Stale data is a bug</h2>
|
||||
<p>If events stop, the dashboard must look broken on purpose: a red last-seen timer beats a frozen pretty chart that implies the room is still live.</p>
|
||||
<h2>Role-specific views</h2>
|
||||
<p>The person on camera needs gifts and comments. The producer needs connection and queue. One layout for both roles produces ignored panels.</p>
|
||||
<h2>End of session</h2>
|
||||
<p>Lock the dashboard into a recap mode: peak viewers, top gifters, disconnect count. That recap is the only slide most clients will read.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Chat moderation during a live is a workflow, not a personality trait. Teams that skip the workflow either freeze on insults or over-block and kill the room.</p>
|
||||
<h2>Write the rules before the show</h2>
|
||||
<p>List banned topics, allowed teasing, and what happens on repeat offenses. If two moderators would disagree, the rule is not written yet.</p>
|
||||
<h2>Keyword alerts versus bans</h2>
|
||||
<p>Alerts are for review. Auto-hide is for unambiguous spam. Mixing them causes either alert fatigue or silent over-moderation. Keep the lists separate and short.</p>
|
||||
<h2>Escalation</h2>
|
||||
<p>First offense: hide or timeout. Second: longer timeout. Third: block and a one-line note in the session log. Skipping steps makes appeals impossible.</p>
|
||||
<h2>On-camera coordination</h2>
|
||||
<p>The host should not read every flagged line. Moderators send a three-word cue when the host must address something. Long Slack essays during a live are a failure mode.</p>
|
||||
<h2>Aftercare</h2>
|
||||
<p>Export flagged messages with timestamps. Review once, adjust the keyword list, and stop relitigating the same clip in group chat for three days.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Viewer charts are useful when they change what you do in the next five minutes. They are decoration when they only confirm that a popular creator is popular.</p>
|
||||
<h2>Read slope, not peaks</h2>
|
||||
<p>A slow climb after a topic change is a stronger signal than a one-second spike from a raid that already ended. Train operators to talk about slope in the recap.</p>
|
||||
<h2>Align events to the curve</h2>
|
||||
<p>Overlay gifts, follows, and topic changes on the same timeline. A dip after a product pitch is information. A dip after a disconnect is a technical incident. Mixing the two in a client report is malpractice.</p>
|
||||
<h2>Sampling</h2>
|
||||
<p>If the source updates every few seconds, do not pretend you have millisecond precision. Store the native interval and label charts accordingly.</p>
|
||||
<h2>Compare like with like</h2>
|
||||
<p>Weekday lunch lives are not Saturday night lives. Compare against the same weekday and timeslot. Cross-slot comparisons create fake emergencies.</p>
|
||||
<h2>Action examples</h2>
|
||||
<p>Rising chat rate plus flat viewers: ask a question. Falling viewers plus gift burst: thank and hold the topic. Charts that never produce an action should leave the default screen.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Session archives are how teams learn. Without them, every live is a rumor. With them, you can answer who gifted, when chat spiked, and whether the disconnect was 20 seconds or 20 minutes.</p>
|
||||
<h2>What to store</h2>
|
||||
<p>Event log (JSON or CSV), a short metadata file (room, start, end, operator), and optionally a recap note. Video is optional and heavy. Start with events.</p>
|
||||
<h2>Naming</h2>
|
||||
<p>Use UTC timestamps in filenames: <code>2026-08-24T1900Z-room-handle</code>. Human titles belong inside the metadata file. Clever folder art does not survive a second operator.</p>
|
||||
<h2>Retention</h2>
|
||||
<p>Decide a retention window before you accumulate a disk of chat logs. Personal data in comments is still personal data. Shorter is usually better.</p>
|
||||
<h2>Export formats</h2>
|
||||
<p>CSV for spreadsheets. JSON for tooling. If your only export is a screenshot, you do not have an archive.</p>
|
||||
<h2>Access control</h2>
|
||||
<p>Chat logs can include phone numbers, insults, and minors’ usernames. Do not dump archives into a shared drive with “everyone” access because it is convenient.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Overnight lives fail for predictable reasons: sleepy operators, silent alerts, and nobody who can restart a frozen client. Coverage is a staffing problem first.</p>
|
||||
<h2>Shifts, not heroics</h2>
|
||||
<p>Four-hour blocks with a 15-minute overlap beat a single person “watching until morning.” Overlap exists so the incoming person sees a live handoff, not a dead laptop.</p>
|
||||
<h2>Alert budget</h2>
|
||||
<p>Night alerts should be rarer and louder. If the phone buzzes for every follow, it will be in another room by 3 a.m. Keep night rules to disconnects and high-value gifts.</p>
|
||||
<h2>Physical setup</h2>
|
||||
<p>Charger, headset, written restart steps, and a backup hotspot. The overnight kit is boring on purpose. Novelty gadgets are for daytime experiments.</p>
|
||||
<h2>Health</h2>
|
||||
<p>Do not schedule the same person for consecutive overnights as a default. Error rates climb. So do accidental bans.</p>
|
||||
<h2>Morning recap</h2>
|
||||
<p>The day team needs: disconnect count, top gifts, unresolved moderation, and whether the host is still live. They do not need a novel.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Notifications are a scarce resource. Each unnecessary ping trains operators to ignore the next one, including the gift you actually needed.</p>
|
||||
<h2>Severity ladder</h2>
|
||||
<p>Info (log only), attention (desktop toast), interrupt (sound or phone). Most events belong in info. If everything is interrupt, you have no ladder.</p>
|
||||
<h2>Wording</h2>
|
||||
<p>Lead with the action: “Thank @user — Galaxy x1.” Do not lead with the product name of your monitoring app. The operator already knows which app buzzed.</p>
|
||||
<h2>Rate limits</h2>
|
||||
<p>Cap toasts per minute per room. Collapse repeats into “12 roses in 20s.” Humans cannot process a firehose and will blame the tool instead of the settings.</p>
|
||||
<h2>Quiet hours</h2>
|
||||
<p>Personal phones need a night profile even if the desktop stays loud. Split channels so family devices are not on the same stream as ops.</p>
|
||||
<h2>Review weekly</h2>
|
||||
<p>If an alert type was never acted on in seven days, demote it. Notification design is maintenance, not a one-time toggle screen.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>A local HTTP API plus an event stream lets other programs subscribe to a live without scraping a window. That is the difference between a toy overlay and a maintainable ops stack.</p>
|
||||
<h2>Read models</h2>
|
||||
<p>Expose current room state (viewers, uptime, last event time) as a cheap GET. Expose history as a filtered query, not an unbounded dump.</p>
|
||||
<h2>Event streams</h2>
|
||||
<p>Server-sent events are enough for most overlays. WebSockets are warranted when you need bidirectional control. Start with SSE unless you have a reason.</p>
|
||||
<h2>Auth</h2>
|
||||
<p>Bind to localhost by default. If you expose beyond the machine, require a token and TLS at the reverse proxy. “It is only on the LAN” is not an access policy.</p>
|
||||
<h2>Versioning</h2>
|
||||
<p>Prefix routes with <code>/v1/</code>. Live ops tools get forked by tired people at 1 a.m. Breaking JSON fields without a version is how overlays die mid-show.</p>
|
||||
<h2>Documentation</h2>
|
||||
<p>One page with example curl calls is more valuable than a generated OpenAPI that nobody opens. Keep the examples accurate when fields change.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>False alerts are not a minor annoyance. They are how on-call culture dies. A live monitor that cries wolf will be muted, and then a real disconnect goes unnoticed.</p>
|
||||
<h2>Common sources</h2>
|
||||
<p>Reconnect flaps, duplicated gift combos, timezone-shifted “new day” counters, and keyword lists that match ordinary slang. Log why an alert fired, not only that it fired.</p>
|
||||
<h2>Hysteresis</h2>
|
||||
<p>Require a condition to persist for N seconds before paging. Viewer drops of one second are noise. Disconnects that last 15 seconds are incidents.</p>
|
||||
<h2>Dedup windows</h2>
|
||||
<p>The same gifter sending the same gift three times in two seconds is usually a combo, not three incidents. Collapse it.</p>
|
||||
<h2>Operator feedback</h2>
|
||||
<p>Add a “not useful” control on toasts. Review the pile weekly. Settings that cannot be tuned will be abandoned.</p>
|
||||
<h2>Never hide failures</h2>
|
||||
<p>Suppressing flaps is good. Suppressing “no events for 90 seconds while the room should be live” is not. Distinguish noisy metrics from dead pipelines.</p>
|
||||
@@ -0,0 +1,16 @@
|
||||
<p>A runbook is a short document you can follow when the host is talking and the producer is already busy. If it only lives in someone’s head, you do not have a runbook.</p>
|
||||
<h2>Pre-show (15 minutes)</h2>
|
||||
<ul>
|
||||
<li>Confirm room id and backup account</li>
|
||||
<li>Start the monitor and wait for first events</li>
|
||||
<li>Test one webhook and one alert sound</li>
|
||||
<li>Note the operator name and shift end time</li>
|
||||
</ul>
|
||||
<h2>During</h2>
|
||||
<p>Who thanks gifts, who mods chat, who restarts the client. Write names, not roles. Roles drift. Names do not.</p>
|
||||
<h2>Disconnect</h2>
|
||||
<p>Numbered steps: check host network, restart capture, verify events resume, post a status line to the team channel. No essays.</p>
|
||||
<h2>End of show</h2>
|
||||
<p>Stop capture, export archive, paste recap bullets, confirm the next shift or that the room is actually off.</p>
|
||||
<h2>Keep it one page</h2>
|
||||
<p>If the runbook needs a table of contents, it will not be read. Link out for deep docs. The page next to the keyboard stays thin.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Creator tooling sprawls until nobody can say what is load-bearing. A checklist keeps the stack small enough to restart under pressure.</p>
|
||||
<h2>Must-have</h2>
|
||||
<p>Stable capture of events, a way to notify a human, and an export. Everything else is optional until those three work on a bad Wi-Fi day.</p>
|
||||
<h2>Nice-to-have</h2>
|
||||
<p>Charts, multi-room, webhooks, mobile companion, widgets. Add one at a time and keep it for two weeks before adding another.</p>
|
||||
<h2>Account hygiene</h2>
|
||||
<p>Shared logins in a chat history are an incident waiting to happen. Use a password manager and revoke access when people leave the roster.</p>
|
||||
<h2>Platform policy</h2>
|
||||
<p>Automation that spam-clicks, mass-messages, or impersonates the official app is not “ops.” It is a ban path. Stay on documented or local-listen approaches your counsel can live with.</p>
|
||||
<h2>Review cadence</h2>
|
||||
<p>Once a month, delete a tool nobody opened. Tool counts only go up unless you schedule subtraction.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Viewer count is the loudest metric and often the least actionable. Engagement is whether people talk, gift, follow, and stay after a topic change.</p>
|
||||
<h2>Chat rate</h2>
|
||||
<p>Messages per minute versus your baseline tells you if the room is awake. A high viewer count with dead chat is a lurking crowd, not a conversation.</p>
|
||||
<h2>Gift participation</h2>
|
||||
<p>Count unique gifters, not only diamond totals. One whale and a silent room is a different show from fifty small gifts.</p>
|
||||
<h2>Follow conversion</h2>
|
||||
<p>Follows clustered after a specific ask are evidence. Follows smeared across the whole session are harder to learn from. Align the ask with a timestamp in the archive.</p>
|
||||
<h2>Stay-through</h2>
|
||||
<p>If you can sample unique viewers over time, look at how many remain 10 minutes after a spike. Raids that bounce teach you not to change the content to chase them.</p>
|
||||
<h2>Pick two</h2>
|
||||
<p>Report two engagement metrics besides viewers. More than that and clients hear noise. Operators cannot optimize seven numbers at once.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Disconnects are normal. Unhandled disconnects are how archives get holes and how hosts talk to an empty capture for twenty minutes.</p>
|
||||
<h2>Detect absence, not just errors</h2>
|
||||
<p>A client can sit in a “connected” UI state while events have stopped. Alert on last-event age, not only on thrown exceptions.</p>
|
||||
<h2>Reconnect policy</h2>
|
||||
<p>Exponential backoff with a cap. Hammering a session endpoint in a tight loop can make a platform issue worse and can look abusive.</p>
|
||||
<h2>User-visible status</h2>
|
||||
<p>Show “no events for 22s” in the operator UI. Hidden retries feel like a freeze. Visible retries feel like a system doing its job.</p>
|
||||
<h2>Host communication</h2>
|
||||
<p>If capture is down, the host may still be live on the official app. Do not tell them to end the stream unless you have confirmed the official player is also dark.</p>
|
||||
<h2>Post-incident</h2>
|
||||
<p>Log start, end, suspected cause (Wi-Fi, app crash, laptop sleep). Patterns across weeks beat a single angry screenshot.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>Live logs contain other people’s messages. Treating them like a private diary for the team is how you get a leak and a policy problem in the same week.</p>
|
||||
<h2>Minimize</h2>
|
||||
<p>Store what you need for ops and recap. You rarely need full message history for ninety days. You often need gift tables and a short moderation excerpt.</p>
|
||||
<h2>Access</h2>
|
||||
<p>Operators on the current roster only. Shared ZIP files on WeChat are not an access-control system.</p>
|
||||
<h2>Redaction</h2>
|
||||
<p>When sharing clips or CSVs with sponsors, strip phone numbers, emails, and obvious personal data. Default to handles, not real names.</p>
|
||||
<h2>Children</h2>
|
||||
<p>If a room attracts minors, tighten retention and sharing. “It was in a public chat” is not a complete answer to a parent or a platform.</p>
|
||||
<h2>Deletion</h2>
|
||||
<p>Have a way to delete a session file. Backups that ignore deletion requests are still copies of the data.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>24/7 monitoring is a hardware reliability problem disguised as a software install. The weak points are power, heat, and sleep policies.</p>
|
||||
<h2>Power</h2>
|
||||
<p>Use a UPS if the building blinks. Disable Windows sleep on lid-close if the laptop must keep running closed—or use a small desktop so lids are irrelevant.</p>
|
||||
<h2>Network</h2>
|
||||
<p>Prefer ethernet. Keep a documented hotspot fallback. USB ethernet adapters are cheap compared with a missed collab.</p>
|
||||
<h2>Heat</h2>
|
||||
<p>A laptop on a bed running capture plus a browser plus a VPN will thermal-throttle and then throttle your attention. Elevate it. Dust the vents.</p>
|
||||
<h2>Displays</h2>
|
||||
<p>A second screen for chat versus charts reduces misclicks. It also increases power draw. Measure before you add a third.</p>
|
||||
<h2>Spares</h2>
|
||||
<p>One spare machine with the client already installed is worth more than a perfect primary with no backup. Image the spare quarterly.</p>
|
||||
@@ -0,0 +1,11 @@
|
||||
<p>New operators fail when training is a screen-share of vibes. Onboarding should be a sequence they can repeat without the senior person on the call.</p>
|
||||
<h2>Day one</h2>
|
||||
<p>Accounts, runbook location, where archives go, and a 20-minute shadow of a real room with no typing privileges. Watching is cheaper than a mistaken ban.</p>
|
||||
<h2>Day two</h2>
|
||||
<p>They handle alerts on a secondary room while a senior owns the primary. Debrief for fifteen minutes. Write down the two mistakes that actually happened.</p>
|
||||
<h2>Permissions</h2>
|
||||
<p>Grant the least access that still lets them work. Admin on day one is how credentials leak into screenshots.</p>
|
||||
<h2>Language and tone</h2>
|
||||
<p>If the host’s room has a specific voice, give three example replies—not a brand manifesto. Operators copy examples. They do not memorize essays.</p>
|
||||
<h2>Offboarding</h2>
|
||||
<p>Revoke tokens the same day someone leaves the roster. Rotate webhook URLs if they had them. Onboarding without offboarding is half a security program.</p>
|
||||
Reference in New Issue
Block a user