Next actions, ranked, from five sources at once
A ranked queue is not a list of findings. Accepted work comes first, goal-serving work next, and a dismissed suggestion never returns even when the rule fires again.
One queue, five sources. Market4's next-action queue collects findings from five families of rules — analytics, tag manager, Search Console, search-result tracking and social — and orders them by what moves the goal that is currently live, not by when each one was noticed. Work somebody has already accepted sits above fresh suggestions, an action tied to the live goal sits above one that is not, and score decides the rest. A dismissed suggestion never comes back, even though the rule that produced it keeps firing.
The five rule families are separate files in the Market4 codebase, each reading one source of data and producing findings in a common shape. Keeping them separate is what makes a rule testable: a rule sees the numbers for its own source and nothing else, and it does not know whether anybody has ever acted on its advice. That ignorance is deliberate, and it is the reason the queue rather than the rule has to remember decisions.
| Rule family | What it reads |
|---|---|
| Analytics | Google Analytics 4 traffic, sources and key events |
| Tag manager | Google Tag Manager containers, tags and publish state |
| Search Console | Impressions, clicks, positions and index coverage |
| Search-result tracking | Tracked queries and how the result page for them looks |
| Social | Published social posts and the metrics collected for them |
The queue applies four comparisons in a fixed order, and the first three exist because a plain score ranking produces a list rather than a plan. An action already ACCEPTED comes before one that is merely SUGGESTED, because showing a fresh suggestion above a decision somebody made is how that decision gets lost. An action tied to the live goal comes before one that is not, which is the point at which setting a goal actually changes what happens next. Score then decides, so the rules' own ranking still means something. Where two rows carry the same score, the one reported more often wins — nine reports and no action is itself a finding.
An agent writing at volume will run out of evidence long before it runs out of topics. There are three honest moves at that point, and inventing a plausible figure is not one of them.
Delete a rejected idea and it becomes indistinguishable from an idea nobody ever had. The next generation run will derive it again, from the same evidence, and propose it again.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Dismissal is stored on the queue row rather than in the rule, and the rule's next run never touches that state. The rule fires again next week, finds the same condition, and updates the row's evidence and count — but a row a person dismissed stays dismissed. A snoozed row is different: it names a day, and it reappears once that day arrives. Without this split, an agent that reads a rules engine every morning would present the same rejected suggestion every morning, which teaches people to stop reading the list.
Recording what an action achieved is the step that makes the queue worth keeping, and it is the step most teams skip. An action that has been carried out can be given a verdict — worked, no change, or backfired — and those verdicts roll up per rule. A rule with a column of backfired verdicts on one account is a rule to stop following on that account, whatever it does elsewhere. Without the verdicts, every rule keeps its standing forever regardless of whether it ever helped.
A snoozed action names a date and reappears in the queue when that date arrives. A dismissed action never reappears, even though the rule that produced it keeps firing and keeps updating the row behind the scenes. Snooze is for work that is real but later; dismiss is for advice that does not apply to this account. Using snooze for both means deciding the same thing repeatedly.
Because somebody already decided to do them. A queue that reshuffles an accepted item below a fresh suggestion loses the decision that was made about it, and the person who made it has to make it again. Score still orders everything below that line, so a high-scoring suggestion is not buried; it sits directly beneath the work already committed to.
Yes, and it is the more useful record. An action marked done can carry a verdict of worked, no change or backfired. Those verdicts are tallied per rule, so a rule that has produced three no-change outcomes on your account is visibly not earning its place. A queue with no outcomes recorded cannot tell a good rule from a loud one.
Yes. A goal is the second comparison the ordering applies, above score: any action tied to the live goal sorts above an action that is not, whatever their scores. That is the point at which a goal stops being a number on a dashboard and starts changing what gets done first. With no live goal, the comparison has nothing to prefer and ordering falls through to score.
The review that matters happens on one page, not on a finished draft. Approve, reject or mark a brief used, and the rejection is kept so the query is not proposed again.