Google Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for paid-search integrations. This package is the "buy/borrow" option for reading campaigns, ad groups, keywords, and performance metrics out of Google AdWords without writing a SOAP client and auth layer in-house. It informs the classic trade-off: a few days of integration work versus owning a brittle, version-coupled API client.
• Roadmap sequencing for marketing analytics. Because v3.0.0 tracks a specific AdWords API client version, it directly constrains how much reporting surface we can expose (spend, clicks, conversions, keyword-level performance) and how often we must schedule maintenance sprints to keep pace with upstream API versions.
• Feature scope for ad-ops dashboards. Supports decisions on whether to ship read-only reporting (campaign/keyword performance pulled into our own BI) versus write operations (bid and budget changes), the latter carrying approval-workflow, audit-trail, and rate-limit concerns this package does not solve for us.
• Caching architecture decision. The move to Doctrine Cache means our caching layer is no longer coupled to Laravel's Cache facade. That is a real product decision: do we accept a second caching abstraction (and its config, Redis/Memcached wiring, and ops surface) in exchange for the package's built-in request caching, or do we wrap the client ourselves?
• Client/internal-tooling prioritization. Typical use cases this unlocks quickly: internal ad-spend reporting for finance, a client-facing campaign performance tab, alerting on budget pacing, and data export to the warehouse. These are usually low-risk, high-visibility wins, which helps rank them against core roadmap work.

When to Consider This Package

Consider adopting when:

• We need read-mostly AdWords reporting inside an existing Laravel app and want to avoid writing auth, SOAP envelope, and selector/paging logic ourselves.
• The team is already comfortable with Laravel service-container/package conventions and can absorb a doctrine/cache dependency.
• The integration is scoped to internal dashboards or scheduled exports, where a version-pinning maintenance cadence is acceptable.
• We are already on (or can move to) the AdWords API generation this release targets — v3.0.0 is a major bump and should be treated as a migration, not an upgrade. Budget a spike to confirm account credentials, OAuth scopes, and the generated client stubs all still behave.
• We can accept the package's caching opinions. Doctrine Cache means our Laravel cache configuration no longer governs this traffic; confirm the ops team is fine with a separate cache pool, TTL policy, and invalidation story.

Look elsewhere when:

• You need the Google Ads API, not AdWords. The AdWords API is a legacy surface with a published sunset; committing new roadmap scope to it is a strategic risk. For anything greenfield or long-lived, evaluate a Google Ads API client (or a managed ads-data vendor) instead.
• You need high-frequency, write-heavy campaign automation (bid management, budget reallocation) — rate limits, partial-failure handling, and idempotency are not what this package is selling.
• The org mandates a single caching abstraction through Laravel's facade, or you are running a cache backend Doctrine Cache does not support well.
• You need vendor-backed SLAs, support contracts, or a documented deprecation policy.
• Nobody owns the upgrade treadmill. Version-coupled API wrappers rot quietly; without a named maintainer, this becomes abandoned code with a broken cron job attached.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can add paid-search performance data — spend, clicks, conversions, campaign and keyword breakdowns — to our existing Laravel application using this package rather than building a Google Ads integration from scratch. That converts a multi-week engineering project into a contained, few-day integration and lets us ship a finance-facing spend report and a client-facing performance view this quarter. Two caveats worth approving explicitly: the new major version is a breaking change that requires a migration rather than a drop-in upgrade, and it targets Google's legacy AdWords API, so we should treat it as a tactical accelerator with a planned exit path to the Google Ads API rather than a ten-year foundation.

To engineering: v3.0.0 is a breaking release on two axes. First, caching moves to Doctrine Cache, so we inherit a doctrine/cache dependency and a cache configuration path outside Laravel's Cache facade — plan for a distinct cache pool, TTLs, and invalidation, and expect existing cache-related config and tests to need rework. Second, the bundled AdWords API client moves to 6.0.0, which typically means regenerated stubs, changed auth flows, and possible removed or renamed classes/methods in our call sites. Treat this as a migration ticket: pin the version, run our existing selectors against a test account before merging, and add a smoke test around auth plus one reporting call so the next upstream bump fails loudly rather than silently. Please also record a decision note on API longevity — if we proceed, we should scope the integration behind a thin internal interface so swapping to a Google Ads API client later is a contained change rather than a rewrite.