Which action fields should be excluded when measuring human actions using Gemini in Workspace?

Google Workspace Developers Q&A
1

I am working with Gemini for Workspace usage logs loaded into BigQuery and trying to build a clean reporting dashboard that measures true human adoption. My goal is to count distinct human interactions (button clicks, prompts, etc.) and exclude any automated system telemetry, backend sub-processes, or workflow/agentic background loops that inflate the numbers via double-counting.

I have a dataset from recent usage (mid-2026), and I suspect several of the ACTION labels represent background processing rather than human clicks.

Could anyone with experience in the Workspace API/telemetry data confirm if our internal assessment of which actions to exclude is correct?

:stop_sign: Actions We Suspect Are System Noise (Planning to Exclude)

We believe the following actions either duplicate a human action (logged simultaneously) or represent background system processes. In addition to excluding actions in the “inactive” event_category, we are scrutinizing the so-called active actions carefully. Are we correct to filter these out to avoid double-counting?

  • classic_use_case_suggest_time_reporting (Suspect: backend success tracking for Calendar time suggestions)

  • classic_use_case_preset_voiceover (Suspect: internal wrapper for applying a voiceover)

  • classic_use_case_drive_search_ai_overview_quota (Suspect: backend quota check)

  • classic_use_case_teleprompter_word_match (Suspect: passive tracking of reading speed/position)

  • generate_ai_function_response (Suspect: API-level event when an agent/model calls an external tool)

  • slide_as_image (Suspect: system capturing a slide to feed to the AI for context)

  • edit_image_gempix1 (Suspect: specific model routing label logged alongside the broader edit_image action)

  • summarize_for_tts (Suspect: intermediary formatting step before text-to-speech executes)

:bar_chart: Full List of Actions in Our Dataset

For context, here is the complete list of unique ACTION values currently present in our active categories (active_conversations, active_generate, active_summarize). If you spot any other actions in this list that are known system noise or agentic background loops, please let me know!

Conversations & Chat:

add_to_calendar, classic_use_case_gemini_app, conversation, conversation_agentic (Note: we want to count the human prompt here, but exclude the resulting agent loop), conversation_canvas, conversation_image, describe_gemini_uses, generate_starter_active_view, generate_starter_deck_gen, generate_starter_freeform, outline, proactive_suggestions_response, summarize_unspecified_file

Generation & Editing:

beautify_this_slide, bulletize, classic_use_case_docs_read_aloud, classic_use_case_sheets_turbofill, condense, custom_prompt, edit_image, edit_slide, elaborate, expand, find_and_organize_within_folder, formalize, generate_avatar_video, generate_avatar_videos, generate_document, generate_form, generate_form_questions, generate_images_in_product, generate_music, generate_music_full_song, generate_page_outline, generate_recording_scripts, generate_search_ai_mode, generate_talkshow, generate_text, generate_videos_from_image, generate_videos_from_reference, generate_videos_in_product, infographic, list_action_items, match_writing_style, paraphrase, proofread, remove_background, source_suggestions, suggest_replies, text_to_speech

Summarization:

catch_me_up, classic_use_case_meet_take_notes_for_me_session, summarize, summarize_file, summarize_items, summarize_long

Thank you in advance for any insight into Google’s specific logging behavior for these features!

2

*Hello, Ted!

Great question, I’ve been working through exactly this problem for our own Gemini adoption dashboard.*

My approach: use event_category as the primary filter, not action names

I keep only rows where event_category is one of active_conversations, active_summarize, or active_generate. This single field is the cleanest discriminator — it handles all inactive_* events automatically and is more stable than maintaining an action-name blocklist as Google continuously adds new labels.

On your 8 suspect actions specifically:

I agree with excluding classic_use_case_preset_voiceover, classic_use_case_drive_search_ai_overview_quota, classic_use_case_teleprompter_word_match, and summarize_for_tts — the names alone signal these are sub-process or passive events. In our data they either don’t appear or fall into inactive_* categories and are filtered automatically.

The three we currently count (and where your input would be valuable):

  • generate_ai_function_response: We treat this as a user invoking a Gemini function in Sheets. However, if this fires inside agentic/workflow loops without a human trigger, it should be excluded — the event_category field should tell you which case you’re dealing with.

  • slide_as_image: We map this to Slides “generate image.” If it fires as a background system capture to provide the AI with slide context (alongside another logged action), that would be double-counting and warrants exclusion.

  • classic_use_case_suggest_time_reporting: The _reporting suffix does suggest this is telemetry for a background success event rather than the user’s original click. We’d lean toward excluding this one.

edit_image_gempix1: Strong agree on excluding this. The gempix1 suffix looks like a model routing label that fires alongside edit_image for the same user gesture — classic double-count.

Two more to scrutinize: generate_starter_active_view and describe_gemini_uses appear in your “active” list but in our analysis these are auto-displayed when opening Gemini (not triggered by a deliberate user action). We exclude them in our fallback filter. Worth checking your event_category for these.

The bottom line: for any action that appears in both active and inactive categories, the event_category field is the authoritative signal — action-name exclusions alone are unreliable for those gray-area cases.

3

Thank you, Rosty! Speedy and smart both, deserving of a prize, or at least my deep appreciation! I will test excluding/including those actions (and I am already with you on excluding all inactive event_category items). When I have findings to share I’ll update anyone following here with a new reply.