Docs

Android AppFunctions Tracking

Gemini can now call your Android app's functions directly. What to instrument when an AI assistant, not a user, triggers the action.

Engagement

Android AppFunctions lets an app expose specific in-app actions — create a task, check a booking, reorder an item — as callable functions that Gemini and other on-device assistants can discover and invoke directly, without a user ever opening the app. Google has described it as letting apps behave like on-device MCP servers: the assistant reads a natural-language request, matches it to a declared function, and executes it locally. Uber, DoorDash and OpenTable are already shipping integrations.

That’s a genuinely new entry point into a product, and most teams’ analytics still assume every session starts with a human tapping an icon. If an AppFunctions call creates an order, updates a record, or completes a booking, and nothing distinguishes that from a normal in-app action, the event stream quietly starts mixing two very different user journeys together. Funnel and conversion numbers built on “the user opened the app and did X” stop being reliable the moment a chunk of X starts happening with no app-open at all — and teams that don’t instrument for it won’t notice until the discrepancy between assistant traffic and reported sessions gets too large to explain away.

Data Points to Track

  • Invocation source: whether an event originated from a direct user action in the UI or from an AppFunctions call, tagged at the point the function executes — not inferred afterwards from missing screen-view events
  • Function identifier and parameters: which declared function was called and with what arguments, so you can see which capabilities Gemini is actually surfacing to users versus which ones sit unused
  • Assistant confirmation step: whether the user confirmed the action within the assistant’s UI before execution, since Android surfaces a confirmation prompt for higher-risk functions and skips it for low-risk ones
  • Execution outcome: success, failure, or fallback-to-app (the function couldn’t complete and handed the user back into your normal UI), since silent failures here are invisible to any human-facing error tracking
  • Post-invocation app open: whether the user opens the full app within a defined window after an AppFunctions call, which tells you whether the assistant is replacing app visits or supplementing them

Setup Steps

  1. Tag every declared AppFunctions entry point with a distinct event source at the moment it’s registered in the Jetpack library, so instrumentation exists before the function ever ships, not retrofitted after Gemini starts calling it.
  2. Log function name and outcome as first-class event properties, not as a subtype of your existing UI-action events, so assistant-triggered activity can be filtered in or out of standard funnels cleanly.
  3. Capture fallback and error paths explicitly — when a function call can’t complete and the OS routes the user into the app instead, fire an event that records why, since this path won’t otherwise appear in either your app-open metrics or your assistant’s own logs.
  4. Set a post-invocation attribution window (for example, 24 hours) to link a later organic app open back to the AppFunctions call that preceded it, so you can measure whether the assistant drives follow-on engagement.
  5. Exclude assistant-triggered events from human engagement metrics by default, with an explicit toggle to include them, so DAU, session counts and screen-view funnels don’t silently absorb non-human traffic as it grows.

Actionable Insights

A rising share of successful AppFunctions calls relative to total app opens tells you the assistant is becoming a real, parallel front door to your product — worth treating as its own channel with its own conversion and retention numbers, not folded into “mobile app” as a whole. A high fallback-to-app rate on a specific function is a signal that its parameter schema or confirmation flow doesn’t match what users are actually asking Gemini for, and it’s worth revisiting the function’s declaration rather than assuming the problem is on the user’s side.

Low post-invocation app opens paired with high invocation volume can look like cannibalisation of your own app usage — the assistant is completing tasks users used to complete inside your product — which is useful information for retention forecasting even before it shows up as a top-line DAU dip.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert