TruAnon Identity vs Traffic Monitor

Traffic Monitor gives you full visibility into how people and bots are hitting your site. Unlike bloated analytics and security plugins, Traffic Monitor focuses on logging raw request data that you control. You’ll know which pages are cached, which bots are visiting, where users are coming from, and how many requests are tied to each IP/browser combination. Perfect for developers, marketers, and site owners who want fast insights—without handing over their traffic data. What Makes It Different ✅ Logs requests for both cached and non-cached pages ✅ Lets you export raw traffic logs as raw CSV for your own analysis ✅ Identifies repeat ad clicks for spotting potential click fraud ✅ Reveals which bots are hitting your site, so you can block them elsewhere (example: Cloudflare) ✅ Tracks IP address, fingerprint, device type, cache status, response code, and more ✅ Displays referrer URLs and query strings ✅ Records the original source of requests by the same visitor as they surf your website ✅ Doesn’t auto-block or inject junk—just clean, useful data ✅ Works great with Cloudflare, caching plugins, and reverse proxies Key Features Logs every page request, including IP address, referrer, user-agent, browser, device, method, and more. Detects cached traffic even if served by Cloudflare, your web host, or a plugin. Identifies bot traffic by bot name and category. View click IDs like gclid and fbclid from ad platforms like Google and Meta. Records repeat ad clicks to detect potential click fraud. Bulk delete or export logs with one click. Search, sort, and drill into data from your dashboard. Built-in help tabs with definitions, setup help, and troubleshooting. Use Cases Debug integrations instantly: Know exactly what URLs are being hit, by which devices, and with what parameters. No guesswork. Spot caching gaps: See which pages are served from cache and which aren’t, even with Cloudflare or plugin-level caching. Understand real-world traffic: Track entry pages, referrers, devices, and browsers—whether human or bot. Catch click fraud signals: Identify repeat ad clicks tied to the same IP/user agent fingerprint or session, even if served from cache. Audit referrers: View exactly which websites or campaigns are driving traffic (including query strings). Filter out noise: Use bot labels and device types to focus only on human traffic when analyzing patterns.

You have profiles. This lets members bring their own confidence of identity to them, and choose how others see and share it. It amplifies a profile. When identity carries weight, members do more of whatever they came to do — and do it more safely. It is voluntary. Members use it because the platform makes it worth using. What shows is theirs to set, and theirs to withdraw at any time, everywhere at once. Confidence of identity is built from a public history that cannot be assembled on demand. Where it is visible, a fraudster gains nothing and carries more risk, and moves on to a less trusted platform. The community sorts itself, without rules or moderation. It is automatic and continuous. Members keep it current by being who they are. The site stores nothing that identifies anyone — a rank, a score, an image address. Everything else is read live when viewed and never written down. Where badges appear Beside member names on comments and post bylines — classic and block themes On the member’s profile (the author page): badge, title, and granted details On UsersWP member profiles and in the members directory — no code Anywhere else via the [truanon] shortcode, the [truanon_card] profile card, or the Badge block [truanon_settings] places the member panel on any front-end page for membership sites What it costs your server Badges render from cached rank and score; no page waits on an API. Styling is self-contained — no Bootstrap, no icon fonts — and every color is a CSS custom property (--truanon-*) a theme can override. Using it with a membership plugin Community plugins render their own profile pages and member directories. WordPress core never fires its author or comment hooks there, so TruAnon reaches them either natively (UsersWP) or with a one-line snippet (everything else). UsersWP — nothing to add. The badge places itself on member profiles and in the members directory (there as a compact rank-colored check, rendered from cache with no per-member API call). On their own profile the owner also sees a Verify / Manage bar that opens their identity panel (anchor + privacy switches). It is on as soon as you enter your key; the setting on the TruAnon admin screen turns the member control off if you’d rather place it yourself. If you ran an earlier version with a [truanon_verification] profile snippet, remove it after updating so the badge isn’t drawn twice. Other plugins (BuddyPress, Ultimate Member, bbPress) — one snippet. Pick the piece you want with a shortcode — [truanon] (pill), [truanon size="inline"] (just the check, no API call), or [truanon_card] (full card); each accepts user="login-or-id" — and place it from your plugin’s profile hook. For BuddyPress, in your theme’s functions.php or a code-snippets plugin: add_action( 'bp_before_member_header_meta', function () { echo do_shortcode( '[truanon_card user="' . bp_displayed_user_id() . '"]' ); } ); Then give those members a place to manage their identity, since they never open wp-admin: put [truanon_settings] on a front-end page (or profile tab). It shows the visitor their own badge and a Verify / Manage button with every privacy switch. (On UsersWP this is the inline switch above, so the shortcode is optional there.) Upgrading from 1.x / 2.x? The old [truanon_verification userid=".." username=".."] shortcode still works. It now renders the current design — an inline check in a members list, the full card on a profile — so existing placement snippets keep working with no edits. Pass size="inline", size="large", or size="card" to force one specific piece. For developers and AI assistants Placement is automatic on stock WordPress (comment authors, post bylines, author archives) and on UsersWP (member profiles and the members directory). On any platform without native support — BuddyPress, Ultimate Member, bbPress, a custom theme — place it explicitly with the surface below. How fetching works (the model): a badge paints from a small per-user cache — rank, score, color — so no page ever waits on the API. TruAnon is called live only when the full badge/card is shown and the member’s identity switch is on; never for a list/inline check, and never for a member who has not turned it on. Each successful call refreshes the cache; the list checkmark reads that cache and never calls out. The call is not gated on a stored “anchored” flag — whether a member is anchored is what the call returns, and it is recorded as a result, never required as a precondition. Shortcodes: [truanon user="login-or-id" size="large|inline"] — the badge. inline is a small check with no API call, for lists. [truanon_card user="login-or-id"] — the profile card: badge and the details the member has granted, read live. [truanon_settings] — the member’s own Verify / Manage control with privacy switches, for front-end membership sites. [truanon_verification userid=".." username=".."] — legacy 1.x / 2.x alias; context-aware. Template tag (PHP): truanon_badge( $user = 0, $size = 'large' ) — $user is a user ID, login, or WP_User; $size is large or inline. Block: “TruAnon Badge” (truanon/badge), attributes user and size. Filters: truanon_userswp_render_badge ( bool, int $user_id ), truanon_inline_manage ( bool ), truanon_inline_link ( string $url, int $user_id ), truanon_absent_text ( string, int $user_id ). To integrate a profile plugin without native support: hook that plugin’s action after the profile name or header and echo truanon_badge( $id ) or do_shortcode( '[truanon_card user="' . $id . '"]' ) on the single profile. In a member directory or loop, use the inline size so each row renders from cache with no per-member API call. Members who never open wp-admin get their own controls from a [truanon_settings] mount on a front-end page.