Here are 12 of the biggest Google I/O 2026 keynote moments, including news about Gemini Omni, Gemini 3.5 Flash and more.

Measuring the true impact of your marketing spend is complex, especially when you look across channels and mediums. In Episode 6 of Google’s Ads DevCast, "The 'What' and 'Why' on Meridian," we sit down with Product Manager Katie Munro and Developer Relations Engineer Jeff Li to explore Meridian, Google's open-source Marketing Mix Modeling (MMM) framework, and how it helps advertisers make data-backed strategic budget decisions.

Watch the full episode

Hear the full episode

Here is a summary of the talking points from our discussion on what Meridian is, how the math works, and the newly announced surfaces to help you implement it.

What is Meridian?

Meridian is Google's open-source Marketing Mix Modeling (MMM) framework. It provides a holistic, privacy-safe view of marketing ROI by analyzing aggregated historical data across all channels (digital, TV, print) alongside non-advertising factors (seasonality, economic conditions). It helps you determine the incremental lift of your marketing (sales caused by ads) versus baseline sales (sales that would have happened anyway).

The Core Math: Hill Curves & Adstock

Meridian uses statistical models to capture the real-world behavior of advertising:

• Hill Curves: Models diminishing returns, showing where you have room to increase spend (headroom) and where you have saturated a channel.
• Adstock: Models the lagged effect and decay of advertising over time, capturing the delay between seeing an ad and making a purchase.

The Measurement Trifecta

Meridian completes the modern measurement framework:

• Attribution (GA4): For day-to-day tactical campaign tweaks.
• Incrementality Experiments (Meridian GeoX): To test specific hypotheses in the real world.
• MMM (Meridian): For macro-level, strategic budget planning.

New Meridian Releases from GML 2026

We discuss three major additions designed to make MMM more accessible and accurate:

• Meridian in GA360: A turnkey, integrated MMM solution within Google Analytics 360 that uses existing behavioral data to provide cross-channel ROI insights without requiring a data science background.
• Meridian Studio: A Google Cloud-based enterprise platform to build and scale models, featuring native agentic AI to automate data quality checks, suggest model health improvements, and assist in scenario planning.
• Meridian GeoX: An open-source geo-based incrementality solution that acts as a calibration engine, allowing you to run geographic experiments and feed "ground truth" causation data back into your Meridian model.

Next Steps:

• Watch the full episode on YouTube (or listen to it)
• Try Meridian: https://goo.gle/try-meridian
• Try Meridian Studio: https://goo.gle/try-meridian-studio
• Try Meridian GeoX: https://goo.gle/try-meridian-geox
• Check out the Meridian Developers website to read the documentation.
• Join our developer community on Discord to ask questions and discuss.

  Cory Liseno Google’s Advertising and Measurement Developer Relations team

  Source: Google Ads Developer Blog

  
  

12 shared lists in Google Maps are packed with Dua’s favorite spots for food, shopping, culture and more.

The finale of Ads Decoded, recorded live at Google Marketing Live 2026, features the teams behind the day’s biggest announcements.

   Hi, everyone! We've just released Chrome 148 (148.0.7778.215) for Android. It'll become available on Google Play over the next few days. 

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

In September 2025, we launched Ask Gemini in Meet, which brings the power of Gemini into your organization’s meetings. Today, we’re excited to announce that we’re making the feature more easily accessible by moving the Ask Gemini prompt box into the bottom left-hand corner of the Google Meet web interface:

You can now easily identify critical irregularities and outliers in your time-series data when using Connected Sheets to analyze BigQuery data sets from Google Sheets. Anomaly detection in Connected Sheets allows users to distinguish between expected trends and true outliers without requiring manual model training or complex SQL knowledge.

Getting started

Rollout pace

Availability

Resources

Google Pay is evolving for "agentic commerce" by introducing the Universal Commerce Protocol and a new MCP server that allows AI agents to manage integrations and analyze trends. New Android updates introduce dynamic callbacks for seamless express checkouts and extend payment support into social media apps via WebViews. Additionally, the platform is launching cross-device biometric authentication and new transaction signals to help merchants reduce friction and optimize processing costs.

Today we’re announcing the upcoming rollout of Demand Gen resource support to all Display & Video 360 API users starting on June 10, 2026. This feature will be rolled out to Display & Video 360 partners over two weeks. By June 24, the feature will be available to all partners.

Ahead of June 10, verify that your API integration can handle the additional Demand Gen line items and ad groups that will be included in list responses once the feature is rolled out to your partner.

What’s changing?

Originally launched in closed beta on April 14, 2026, Demand Gen resource support includes management and retrieval capabilities for Demand Gen resources and their targeting.

Demand Gen resources include the following:

• LineItem resources with a lineItemType field value of LINE_ITEM_TYPE_DEMAND_GEN.
• AdGroup resources with an adGroupFormat field value of AD_GROUP_FORMAT_DEMAND_GEN.
• AdGroupAd resources using any of the following fields: demandGenVideoAd, demandGenImageAd, demandGenCarouselAd, demandGenProductAd. Demand Gen AdGroupAd resources are retrievable using Display & Video 360 API currently, but these fields will not be included in the retrieved object until full support is rolled out to your partner.

After these features are rolled out to your partner, the API will support get, create, delete, and patch requests for these resources. In addition, these resources will be included in advertisers.lineItems.list and advertisers.adGroups.list responses, alongside the line items and ad groups that are already supported.

What actions do I need to take?

If you are currently retrieving LineItem and AdGroup resources using advertisers.lineItems.list and advertisers.adGroups.list, update your integration by June 10, 2026 to support the Demand Gen resources that will be included in responses once the features are rolled out to your partner.

The other features included in this rollout add support for Demand Gen resources that are explicitly identified when using new or existing methods. These changes only impact requests that would have previously returned an error, so no changes should be needed beforehand to ensure the stability of your integration.

Once the features are rolled out to all partners after June 24, 2026, you can start explicitly retrieving, creating, and updating Demand Gen resources. See our existing guide for step-by-step instructions on how to begin serving Demand Gen ads using the Display & Video 360 API.

We will make another announcement once this rollout begins. If you have any questions or want to discuss this post, please reach out to us on our “Google Advertising and Measurement Community” Discord server.

- Trevor Mulchay, Display & Video 360 API Team

by Alex Stephen & Talat Uyarer, Lakehouse

Apache Iceberg project has just launched version 1.11.0! A lot has happened since the last version.

Iceberg 1.11.0 adds support for Apache Spark 4.1 and Apache Flink 2.1, the latest releases of the two engines and makes both the default build targets

The rest are more structural. The REST catalog learns to plan scans server-side, shifting metadata work off the query engine. A new partition statistics scan API gives optimizers a clean, supported way to read a table's shape. Built-in table encryption arrives with envelope encryption and Google KMS support. And Google Storage Analytics library integration makes your Iceberg workloads faster than before.

Let's take a look at some of the biggest changes.

Spark & Flink Updates

As Spark and Flink are moving forward, the 1.11.0 release is pushing forward for new version support in both.

• Spark 4.1 & DSv2 Migration: Spark 4.1 unlocks is MERGE INTO with automatic schema evolution: Spark's newer MERGE syntax accepts a WITH SCHEMA EVOLUTION clause, so a MERGE whose source carries columns the target table lacks can add those columns to the table within the same statement, with no separate ALTER TABLE round trip. Beyond the version bump, the 1.11 Spark connector also modernizes against Spark's newer DataSource V2 APIs and adds an asynchronous micro-batch planner that speeds up Structured Streaming.
• Flink Ecosystem Updates: Initial work for Flink 2.1 support has landed in the core repository, continuing Iceberg's promise of providing first-class, low-latency streaming sink capabilities. The centerpiece of the Flink work is the DynamicIcebergSink, an experimental sink that breaks the old one-sink-per-table model: a single sink routes each record to a table chosen at runtime, creating tables on demand and evolving their schemas and partition specs on the fly as the input changes including dropping columns once you opt in with dropUnusedColumns. In addition to DynamicIcebergSInk work Flink started supporting nanosecond, variant and unknown types from V3 Spec.

Server-side scan planning

In previous versions of Iceberg, the client handled the heavy lifting of scan orchestration. The driver of engine would traverse the table's metadata tree, retrieving manifest lists and files from object storage to filter data against specific partition requirements. Iceberg 1.11.0 shifts this computational burden into the catalog through server-side scan planning.

Instead of manually traversing manifests, the engine submits a single POST …/plan request detailing the scan allowing the REST catalog to return optimized FileScanTasks.

The API is designed to handle data at any scale: smaller scans return immediate results, extensive operations return a plan-id for polling, and massive datasets are retrieved via parallel plan-tasks through POST …/tasks.

Built-in table encryption

As data lakes increasingly serve as the central hub for sensitive PII and financial data, relying solely on bucket-level storage encryption is no longer enough. Iceberg 1.11.0 introduces built-in table encryption, bringing fine-grained, KMS-backed security directly to the table level.

This provides data platform teams with robust capabilities for security and compliance:

• Zero-Trust Storage Security: Even if a malicious actor gains direct access to your underlying object storage bucket, the data remains completely unreadable.
• Total Index Protection: It isn't just the raw data that is protected; Iceberg encrypts the manifest lists as well, preventing attackers from inferring sensitive information from table statistics.
• Tamper-Proof Data: Built-in authentication tags guard against unauthorized modifications, ensuring data integrity.
• Effortless Key Rotation: Keys are rotated automatically as they age, satisfying strict compliance mandates without requiring you to rewrite massive datasets.

Iceberg achieves this using envelope encryption with a three-tier key hierarchy. A table master key lives securely in your KMS and never touches Iceberg storage. This master key wraps key-encryption keys (KEKs), which are stored safely inside the table metadata. Finally, each KEK wraps a unique, per-file data-encryption key (DEK).

Every data file and manifest list is then encrypted with AES-GCM under its own unique DEK. This decoupled architecture ensures maximum security while maintaining the high performance expected of Iceberg workloads.

File Format API

Historically, Iceberg's format-handling code was tightly coupled, growing organically around Parquet, Avro, and ORC. Adding a new format or enforcing consistent feature support (like V3 default values or new column types) across all formats meant duplicating complex engine-specific switch/case code paths.

Iceberg 1.11.0 introduces the finalized File Format API, bringing a consistent API to reading and writing all of these file formats.

Instead of hardcoded engines handling binary extraction, the architecture introduces:

• FormatModel: A standardized implementation defining how a file format handles reader/writer construction and its specific capabilities.
• FormatModelRegistry: A central directory where query engines fetch appropriate read and write builders.

This API (which is already seeing adoption around other Apache Iceberg implementations) provides a significant code cleanup for the future of the project. It also opens the door for more file formats as time goes on.

Moreover, this new interface facilitates the implementation of Column Families, enabling vertical partitioning of storage. This advancement lets teams perform targeted updates or rewrites on isolated columns—such as recalculating vector embeddings—while leaving the remaining table data undisturbed.

SQL UDF Specification

1.11.0 includes the SQL UDF specification, which adds a brand new metadata format for both Scalar and Table Functions:

• Immutable Versioning and Rollback: UDF metadata is written as self-contained, versioned JSON files stored right in the object store. If a data engineer deploys a buggy UDF update, administrators can execute an atomic rollback to a previous version log state
• Standardized Schema Typings: Parameters and return types map cleanly to Iceberg Type JSON representations, directly accommodating complex nested maps, structs, and the upcoming Iceberg V3 variant type.
• Engine Specific Execution: Each SQL UDF has a function implementation for each engine, allowing users to leverage engine-specific functionality in their UDFs.

Google Analytics Library Integration

For Google Cloud customers, version 1.11.0 delivers substantial throughput gains by embedding the GCS Analytics Core library into GCSFileIO (Issue #14326, PR #14333).

This integration introduces Footer Prefetching, which optimizes Parquet length checks by caching object suffixes to remove network overhead. Combined with threaded VectoredIO for concurrent multi-range operations and specialized small object caching for sub-1MB files, these enhancements eliminate persistent I/O bottlenecks. Initial benchmarks indicate that these architectural improvements can reduce Parquet metadata parsing latency and boost total record processing speeds, empowering high-scale Spark, Flink, and Trino workloads to run with improved efficiency on Google Cloud Storage.

Getting Started with 1.11.0

We are excited to be part of the Apache Iceberg community and innovating together. As a compliant Iceberg REST Catalog, Lakehouse for Apache Iceberg (formerly BigLake) already has support for version 1.11.0.

To upgrade your environment, update your build dependencies to version 1.11.0. Remember to review your deployment runtimes to ensure compatibility with the new JDK 17 baseline, and test your workloads if you are transitioning from Spark 3.4.

For a full breakdown of every bug fix, contributor attribution, and dependency bump, check out the official Apache Iceberg Releases Page