View tracking and the debug log are two separate switches, and they solve two different problems as you build your app:

• View tracking counts how often app users open each piece of content, so you can see what’s popular and surface “most viewed” lists.
• The debug log (shown in the admin as the Admin Log) records what the MAM Suite plugins are doing on the server, so you can confirm a setting took effect, or figure out why it hasn’t.

This article walks through turning on each one, where to find what they record, and how to read it. They’re grouped together because you’ll usually reach for both at the same point in building your app: you’ve just configured something, and you want to see whether it’s actually working.

Before you start

Part 1 — Enable view tracking

What “Track Page Views” does

Turn this on, and here’s what happens: every time a signed-in app user opens a content item, the app pings the server, and the server records two things.

• It increments a running total on that item, so each item carries its own lifetime view count.
• It adds the item to that user’s personal read history, so the app can tell which items a user has already seen.

If the viewer is the item’s own author, that count doesn’t move — a content creator opening their own post can’t inflate its own numbers.

This same flag travels down to the mobile app in its configuration payload — the bundle of settings the app pulls from your site — so the app knows whether it should be sending those view pings at all. Turn tracking off, and the app simply stops pinging; nothing gets recorded.

It’s not limited to one type of content, either: the server logs a view against whatever item the app opens, so any post type your app surfaces can build up a count.

Steps

1. In the WordPress admin, open Mobile App Mgr.
2. Go to the app settings and open the General Settings group.
3. Locate the setting labeled Track Page Views.
4. Set it to Yes.
5. Save.

That’s the whole setting — a simple Yes/No toggle, nothing else to configure. Counting kicks in on the next app sync, as soon as the app picks up your updated configuration.

Where the data shows up

Once tracking is on and people start opening content:

• Each item accumulates a lifetime total view count on the server.
• Each signed-in user builds up a read history, which the app can use to mark items as already seen and to drive “most viewed” or “recently viewed” style screens.

You can put these counts to work right on your home screen: a Home Page Views option lets a home section be driven by view data. The choices there come from a plugin — until one’s installed to supply them, None is the only option you’ll see.

A note on privacy

Worth knowing: view tracking records which signed-in user opened which item. If your app has its own end-user accounts, make sure that’s reflected in whatever privacy disclosure you ship with it. Anonymous, not-signed-in opens aren’t attributed to a person — though the item’s lifetime total can still increment.

Part 2 — Open and use the debug log (Admin Log)

The debug log is an admin-only screen showing a running list of messages the MAM Suite plugins leave behind as they work. It’s the first place to check when a setting doesn’t seem to have taken effect, or when an app screen isn’t loading the data you expected.

What it is

Under the hood, the platform exposes a logging helper (mamdebug()) that plugins call to jot down what they’re doing. Those notes land in a dedicated database table and show up on the Admin Log screen. Each entry carries:

• Date — when it was recorded.
• Tag — a label for the part of the system that wrote the message.
• Plugin — which plugin recorded it, when supplied.
• Message — the detail (text, or serialized data).

The log tidies up after itself, too: it keeps roughly the most recent couple of thousand entries and trims the rest automatically, so it never grows without bound.

Open it

1. In the WordPress admin, open Mobile App Mgr.
2. In its submenu, click Admin Log.

You’ll land on the App Manager Debug Log page, with the most recent entries listed first.

Read and filter it

• Entries are listed newest-first.
• A Tag dropdown above the list lets you narrow things down to one part of the system, showing only messages carrying that tag — handy when one plugin is being chatty and you only care about another. Pick No Filter to bring everything back.
• A Clear Log link clears entries. With a tag filter active, it narrows to Clear [tag] Items and only removes that subset; with no filter, it clears the whole log.

There’s no “enable” switch — but there is a caveat

Unlike view tracking, the Admin Log has no on/off setting in General Settings — the screen is always there for admins, and messages pile up as the plugins run. The one thing worth confirming is that the underlying log table exists. If it doesn’t, you’ll see a “Debug table not found” notice instead of entries, and nothing is being recorded.

That table gets created automatically — mam-main builds it (and its other tables) when the plugin activates, and double-checks it on every admin page load whenever the plugin updates. In normal use, you won’t see the “table not found” notice. If you do, it just means table creation didn’t finish — deactivating and reactivating mam-main re-runs the setup and creates the table.

Putting them together

Here’s what a typical “building your app” loop looks like:

1. Turn on Track Page Views so you can start measuring engagement as you test.
2. Configure a home-screen section, a button, or a plugin.
3. Open the Admin Log to confirm the plugins picked up your change and to see any warnings.
4. Open the app, exercise the feature, and check the log again for the messages it produced.

View tracking answers one question: what are people doing in the app? The Admin Log answers another: what is the backend doing, and did your change actually take? Use them together, and you close the gap between making a change and knowing whether it worked.

Troubleshooting

Verification

This article was drafted against:

• mam-main/includes/app-settings/admin-settings-page.php — the track_views setting definition (category general, label Track Page Views).
• mam-main/includes/helper-classes/user-manager-classes.php — mam_ping_item_view(), which increments total_views and updates read_history, with author exclusion.
• mam-main/mam-main.php — registration of the mam_ping_item_view action.
• mam-main/includes/helper-classes/debug-handler.php — the mam_debug_handler class, the Admin Log submenu, the mamdebug()/mam_log_item() helpers, log pruning, and the Clear Log behavior.
• mam-main/includes/grid-classes/debug-grid.php — the mam_debug_grid list table used to render and filter entries.
• mam-main/user_docs/06d-mobile-json-shape.md — confirmation that track_views is passed to the mobile app in the configuration payload.

Re-verify whenever the Track Page Views setting moves or is renamed, the view-ping/author-exclusion logic changes, the Admin Log menu placement changes, or the log table lifecycle (creation, pruning cap) changes.

Related articles

• App Setting Reference: Track Page Views
• Building Your App: Configure your home screen sections
• Troubleshooting: Reading the Admin Log