Community Stats — one block that fits wherever you put it
Invision's built-in stats block shows three things: total members, most ever online, and the newest member. No posts, no topics, no sense of whether any of it is growing.
This shows what a visitor actually wants to know, with the trend behind it — and it reflows to whatever space you give it.
The same block, both orientations
It measures its own container, not the browser window. Drop it in a 260px sidebar and it renders as a neat stacked list. Drop it across a content column and the same block becomes a row of tiles. Nothing to configure and no second block to maintain — a normal responsive block cannot do this, because a viewport media query cannot tell a narrow sidebar from a wide page.
If you would rather decide yourself, you can force it to always stack or always tile.
Who's online, with faces
A row of avatars linking to profiles, with an overflow count when there are more than will fit.
Anonymous browsing is respected, properly. A member who has chosen to browse anonymously is never shown and never counted — and neither are guests or search engine spiders. The number beside the avatars is derived from the same list that draws them, so the count and the faces can never disagree with each other.
Figures that mean something
Counts
Members, topics, posts, online now, newest member
And, if you run them
Files, images, blog entries, events
Trend
A rise or fall over a period you choose
Sparkline
A 30-day line beside each figure
Only the figures your community can actually produce are offered — install Gallery and an image count appears in the list by itself. Nothing runs a query for something you are not showing.
Trends work on the first day
Members, topics and posts can be rebuilt from their own timestamps, so one click gives you a month of history immediately rather than asking you to wait a month for the block to look finished. Everything else starts recording from now.
And until there is real history, no trend is shown at all. A "+0" on a fresh install would be a lie dressed up as data.
Built to sit on a busy page
Cached. Counting every row on a large community is not free, so figures are shared between visitors for an interval you set.
No JavaScript. The sparklines are drawn inline as SVG — no charting library is loaded, on any page the block appears on.
Big numbers stay readable. 12,300 becomes 12.3k rather than breaking the layout of a sidebar.
Follows your theme, or takes an accent colour of your choosing.
No core files are edited. Upgrading Invision Community will not break it.
Requirements
Invision Community 5.0 or newer (self-hosted)
Forums, Downloads, Gallery, Blog and Calendar are all optional — the block simply offers whatever you have

Quests — give your members something to chase
New members join, look around, and drift away because nothing tells them what to do next. Quests gives them a clear path: a set of goals, visible progress, and a reward when they finish.
Set up a quest once and it works retroactively — members who have been around for years see their real progress the moment you publish it.
How it works
Create a quest, then add the steps a member has to complete. A Getting Started quest might be: make 5 posts and upload a profile photo. A Community Regular quest might be: 100 posts, 5 topics started, 30 days as a member, and 10 reactions received.
Members see a board showing every quest, a progress bar, and a tick-list of the steps with their own numbers beside each one. There is nothing to claim and no button to press — progress updates as they take part, and rewards arrive on their own.
Eight goals to build from
Posts made
Topics started
Reactions received
Reactions given
Days as a member
Achievement points earned
Followers gained
Profile photo uploaded
Every one of these is read from activity your community already records. Nothing new is tracked, nothing needs backfilling, and switching the app on costs you no data.
Rewards that actually count
Finishing a quest awards your community's own achievement points and, if you like, an existing badge. Quest rewards flow straight into ranks, profiles and leaderboards — they are not a separate scoreboard sitting off to one side.
Each quest pays out exactly once. The completion is recorded before the reward is issued, so a member can never be paid twice.
What you control
Title, description and icon for each quest
Any number of steps, in the order you choose
How many achievement points completing it is worth
Which badge to award, if any
Whether the board is visible to signed-out visitors
Enable or disable a quest without deleting it
The admin screen shows how many members have finished each quest, so you can see which goals are landing and which are pitched too high.
Requirements
Invision Community 5.0 or newer (self-hosted), with the Forums application
Nothing else — no external service, no API key, no extra infrastructure
Built to stay out of the way
Progress is recalculated when a member posts, when they open the board, and by a nightly background task that catches time-based goals like "member for 30 days". Quest bookkeeping is wrapped so it can never interfere with someone posting.
It is upgrade-safe — it reads Invision Community's own data and never edits a single core file.

Pulse — traffic analytics that never leave your database
Invision Community tells you a great deal about your content. Registrations, posts, reactions, badges, points, solved rate — there are forty statistics screens in the AdminCP and they are genuinely good.
None of them tell you about your traffic. Not pageviews. Not visitors. Not where anybody came from. Guests, who are most of the people reading your community, appear nowhere at all — they exist only in the sessions table, which is wiped continuously.
The official answer is Google Analytics
Invision Community ships an integration whose entire job is injecting Google's tracking script into your pages. That is the supported route, and for a lot of communities it is not a route at all: a cookie banner, a data-protection question you would rather not answer, and your members' browsing habits handed to an advertising company.
Pulse is the third option. Every figure below is measured on your own server, stored in your own database, and shown in your own AdminCP. Nothing is sent anywhere.
What it measures
Headline
Pageviews · visitors · sessions · bounce rate · average visit length
Where they went
Top pages, with the whole path — not just content items
Where they came from
Referring sites, with your own domain excluded
Who
Members against guests, and desktop against mobile and tablet
Countries
A world map you can hover, country by country
Every headline figure carries a trend line, and the whole dashboard can be read over seven, thirty or ninety days.
No JavaScript. No cookies. No IP addresses.
This matters enough to be specific about, because "privacy-friendly" is easy to claim.
No script is loaded. Not one byte of JavaScript, not even for the charts — the graphs and the world map are inline SVG. Nothing is fetched from anywhere.
No cookie is set, so Pulse adds nothing to a consent banner.
No IP address is ever written to the database. One is read to compute a hash and immediately discarded. There is no column to store it in.
The visitor identifier is salted with a secret that changes every day. It cannot be reversed, and it cannot be matched from one day to the next — so it counts visitors without following anybody.
A pageview records whether somebody was signed in, never which account. There is no member column.
Raw events last hours, not for ever. They are rolled into daily totals and deleted. After that a day exists only as a handful of numbers.
The settings screen lists all of this in the interface, with live counts, so you can answer a data-protection question by pointing at it.
It cannot slow your forum down
The recording happens after the page has already been delivered. Invision Community closes the connection to the browser before running its shutdown work, and Pulse writes its single row at that point. The visitor has their page before the database is touched. There is no query on the way in, no join, and nothing that can fail in a way that affects the page.
Honest about the limits
Some things cannot be measured without JavaScript, and it is better to say so than to invent them:
A one-page visit has no measurable length. There is no exit signal, so bounces contribute nothing to the average visit time rather than a made-up figure. The average is over visits that can actually be measured.
Visitors are counted per day and added up. Somebody who comes on Monday and Tuesday counts twice over a week. Counting them once would mean keeping the raw records for the whole period, which is exactly what this app is designed not to do.
Countries need a header from in front of your site. If you run Cloudflare or a load balancer that provides one, the map fills in. If nothing supplies it, the map is hidden rather than shown empty. Pulse does no geolocation lookups of its own — that would mean either an external request or shipping a database of IP ranges.
Also
Crawlers are separated out, using Invision Community's own spider detection. Search engines can be most of your raw traffic and none of your audience.
You can exclude your own staff, so your browsing does not become the story.
Retention is yours to set — hours of raw events, days of history.
No core files are edited. Upgrading Invision Community will not break it.
Requirements
Invision Community 5.0 or newer (self-hosted)
A running task scheduler — the hourly rollup is what produces every figure
Nothing else. No API key, no account, no external service.

Drip Campaigns — email sequences that run themselves
Somebody registers at three in the morning on a Saturday. A week later they have posted nothing and you have not spoken to them, because nobody was awake to. Multiply that by every member who ever joined and you have the reason most communities lose people in their first fortnight.
A drip campaign is a sequence of emails that starts when a member does something and then unfolds on their clock — a welcome straight away, a nudge two days later, an invitation to introduce themselves after a week. Everyone gets the same thoughtful onboarding regardless of when they arrived.
Invision Community has this. On Cloud. On some plans.
Email Drip Campaigns arrived in Invision Community 5.1 for Cloud customers, on selected packages. Self-hosted communities do not get them at all.
This app brings sequences to self-hosted — and adds the two triggers the Cloud version does not have. Both were the most-requested things in the comments under the announcement, and neither made it in.
The trigger nobody else offers: they stopped showing up
Every other trigger is an event — somebody did a thing, so something happens. Absence raises no event. Nobody fires a notification when a member quietly stops visiting, which is exactly why re-engagement is the hardest email to send and the one worth the most.
This app goes looking instead. Set a number of days, and members who cross that line are enrolled by a scheduled scan. A "we miss you" series that actually reaches the people it is about.
And renewals, which are not first purchases
Invision's Cloud version fires on "purchases a subscription". This one also fires on renewals, on an upcoming expiry — the moment worth acting on while there is still something to save — and on cancellations. Thanking a three-year customer for joining reads badly; these deserve different emails and now they can have them.
Every trigger
Joining
Registers · confirms their email · updates their profile
Taking part
Joins a club · responds to an event · completes a course
Money
Buys · renews · is about to expire · cancels
Absence
Has not visited for a set number of days
Chaining
Another campaign finishes
Event responses can be narrowed to one answer, so you are not telling somebody who declined that you will see them there. Triggers for applications you do not run are never shown, and never listened for.
Audiences built from filters you already have
This app invents no filters of its own. It uses Invision Community's own member filters, which means you can target by group, join date, last visit, content count, reputation, achievements and profile fields — and, if you run Commerce, by purchases, subscriptions, total spend and donations.
Anything a third-party application adds to that list works here too, automatically.
It checks again before every email
This is the part that stops a campaign embarrassing you. Someone qualifies for "we miss you" on Monday, comes back on Tuesday, and on Wednesday the second email arrives telling them how much you miss them. Audiences are re-checked before every send, not just at enrolment, so a member who stops matching stops receiving. It can be switched off; it is on by default for a reason.
Care taken where it matters
Opting out is honoured absolutely. A member who has turned off administrator emails is never enrolled, never sent to, and is removed from a campaign if they opt out mid-sequence.
Unsubscribing uses Invision Community's own mechanism — the same link, the same page, and a key derived from the account so it stops working when the password changes.
Nobody is enrolled twice. A trigger that fires more than once for the same person does nothing the second time.
Disabling an email does not strand anyone. Members waiting on that step move to the next one rather than sitting there for ever.
Posting and paying never wait on email. Enrolment happens in the background; sending happens on a schedule.
No core files are edited. Upgrading Invision Community will not break it.
Check a member
"Why didn't they get it?" has a dozen possible answers. There is a screen that gives you the actual one: whether they can be emailed at all, whether they match each campaign, whether they are enrolled, which step they are on, and when the next email is due.
Requirements
Invision Community 5.0 or newer (self-hosted)
Working outgoing email and a running task scheduler
Commerce, Calendar, Clubs are all optional — their triggers appear only if you run them

Most of the people reading your community are not members of it. They arrive from a search result, read the answer they came for, and leave — and nothing about that visit is recorded, so you never find out which of your topics were the ones worth joining for.
Convert does two things: it asks them to join at the moment they are most likely to say yes, and it tells you which pages actually worked.
Ask at the right moment
Invision Community's guest sign-up block is a static panel in the sidebar. It says the same thing to somebody who has just landed as to somebody who has read six topics and is scrolling to the bottom of a seventh.
Convert puts the prompt where the visitor already is, and only when it makes sense:
The reply box
Where a signed-out visitor is told they need an account to reply. They have read to the bottom of a discussion and want to say something — the strongest moment the software has.
Under the discussion
At the end of the posts on a topic.
Every page
The foot of any page, including Downloads, Pages and Gallery.
And only to the right people. Show it after somebody has read two pages, not one. Show it only to visitors who arrived from a search engine. Show it only in the forums where it makes sense. Show it at most twice a visit, so it never becomes wallpaper.
"No thanks" is remembered. When a visitor dismisses a prompt it stays dismissed, for as long as you choose. Nothing is more likely to lose a reader than asking them the same question on every page after they have already said no.
Then find out what actually worked
Every prompt is measured the whole way down: shown, clicked, joined, posted. Not just the click — the click is easy. The number that matters is at the bottom.
What brings people in
The pages people were reading when they decided to join, ranked. Usually a surprise, and usually the most useful screen here — it tells you what your community is actually good at before you write another word of copy.
Where they came from
Search, social, another site, or direct — recorded from the first page of the visit, so it survives them clicking around.
Compare two versions
Give two prompts the same test name and each visitor sees one of them, consistently, for their whole visit. Then read the two rows side by side.
It counts the people who joined without being asked, too. That is the number every prompt is competing against, and leaving it out is how conversion reporting ends up permanently flattering. If forty people joined unprompted last month and three came through a prompt, you have learned something real.
Honest about what it shows
A rate with nothing behind it is shown as blank, not as 0%. "Never shown" and "shown a thousand times and ignored" are opposite findings, and printing zero for both hides the difference exactly when you need it.
Impressions are counted on the server, as the page is built. Counting them with a script means an ad blocker can delete them, which quietly inflates every click rate you look at.
Posting is tracked separately from joining. A prompt that produces accounts which never post has produced nothing, and the report is built so it can say so.
What it collects
Daily totals per prompt — shown, clicked, dismissed. No row is ever written per visitor. The only per-person record is one row for each member who registers, so that the report can say which page brought them in; it is created at registration and belongs to a member you already have.
The only cookie it sets exists to remember that somebody pressed "No thanks". Everything else rides the session Invision Community already keeps.
Requirements
Invision Community 5.0 or newer (self-hosted)
Registration open to guests, which is what there is to convert them to
Nothing else. No account, no key, no external service.

Cohorts & Retention
Invision Community can tell you how many members you have and how many joined last month. It cannot tell you the thing that actually matters: of the people who joined in March, how many were still here in April? In June?
That single question is the difference between a community that is growing and one that is churning while the registration counter goes up.
The grid
Every row is everyone who joined in one month. Reading across shows how many of them came back one month later, two months later, and so on. Reading down a column shows whether the community is getting better or worse at keeping people — which is the number to watch after you change anything about registration, onboarding or moderation.
Twelve months of history, on the day you install it. This reads data Invision Community has been keeping since your community started, so the grid is complete from the first build. Nothing has to accumulate first.
Two definitions of "still here", because they answer different questions
Signed in
The broad measure. Includes people who read without ever posting, who are the majority of any community. Answers: are they still turning up?
Posted something
The hard measure. Any content in any application — a forum reply, a file, a blog comment. Answers: did they become a participant, or just an audience?
Both are worth looking at, and the gap between them is often the most interesting thing on the screen.
It collects nothing
There is no tracker, no new logging and no external service. Everything comes from three things your community already stores: when each member registered, the record of which days they signed in, and the index of who posted what and when. Uninstalling removes only this application's cached grid.
The grid is built in the background, never while you wait. Building it compares every member against their whole history, so it runs as a background job and stores the result. Opening the screen reads a small cached table — it does not recompute anything.
Honest about what it shows
Periods that have not happened yet are left blank, not shown as zero. A cohort that joined last month has no month-6 figure. Printing 0%% there would read as "everybody left" when the truth is "we do not know yet", and that difference matters when you are deciding whether something is wrong.
Month 0 is rarely 100%%. It is the month people joined, so anything missing is people who registered and never came back at all — one of the more useful numbers on the grid, and one most analytics never shows you.
Activity dated before somebody joined is discarded. Imported members, merged accounts and hand-edited join dates all produce it. It is dropped rather than shown in a column nobody can interpret.
Small cohorts are noisy. A cohort of nine people moves 11%% every time one person returns. The grid shows the underlying counts on hover for exactly this reason.
Also
Weekly or monthly cohorts. Weekly is worth using when you are measuring something specific — a launch, a campaign, a change to registration.
Up to 36 periods across, though twelve is usually where the interesting part has already happened.
No core files are edited. Upgrading Invision Community will not break it.
Requirements
Invision Community 5.0 or newer (self-hosted)
A running task scheduler, to build the grid in the background
Nothing else. No account, no key, no external service.