Google Ads App Campaign for Indie Games: Avoid Junk Installs

One indie developer's 15-day Google Ads campaign had a $2 daily budget and a $0.003 target cost per install. It delivered 5,000 installs and four reviews, according to the developer's own write-up. The developer says the installs came from places like Bangladesh, Afghanistan, Syria, Iran and Libya, that none of those users played, that many phones could not run the game, and that the crash rate spiked.

Those numbers are one person's result, not a benchmark. Treat them as a warning about what can happen when the install count is the goal. This guide gives you a checklist for a first Android campaign on a budget under $100, so you can tell real players from junk installs within days.

Why a very low target CPI can fill your game with junk

An app campaign optimizes toward the goal you give it. If that goal is installs at the lowest possible price, cheap installs are what you ask for, and cheap installs are not guaranteed to be players.

This is an inference from the write-up, not a claim about how Google's systems work internally. The developer set a $0.003 target per install and then reported a flood of installs from countries where, the developer says, phones could not run the game. A target set that low may push delivery toward whatever inventory is cheapest, whether or not those people can play.

The damage goes beyond wasted money. Crashes on unsupported devices show up in your Play Console stability data, which is tied to your store listing.

Step 1: Fix compatibility before you spend anything

Compatibility problems are cheaper to fix before the campaign than after. Start in your Godot project, then move to Play Console.

Check your Godot Android export preset

This section applies to Godot 4.x. Menu labels shift between minor versions, so confirm them in your own editor.

Open Project > Export and select your Android preset. Enable Use Gradle Build if you need a custom minimum SDK, since that setting sits in the Gradle section in 4.x. Under Architectures, enable arm64-v8a, and decide deliberately whether to include armeabi-v7a. Check Google Play's current 64-bit requirements in Play Console before you drop anything.

Also check your rendering method in Project Settings. Forward+, Mobile and Compatibility have different hardware demands, and Compatibility targets older or weaker GPUs. If your game is a simple 2D or light 3D title, test it on Compatibility. A low-end phone that crashes on a heavier renderer is exactly the kind of device an ad campaign can find.

Review the Play Console device catalog

In Play Console, find the Device catalog section. Navigation changes over time, so use the search bar if it has moved. The catalog lists the devices that can install your current release and lets you exclude devices or groups. We cover related ground in how to compare software development quotes like for like.

Exclude devices you know crash, and note why. Do not exclude blindly, because each exclusion shrinks your audience. After excluding, confirm that the supported device count still looks reasonable for your game.

Capture a stability baseline

Before the first ad runs, open Android vitals and note your crash rate and ANR rate. If the game has almost no installs, the numbers may be empty or noisy. Write down what you see anyway, with the date, so you can compare once the campaign starts.

Step 2: Log device details at startup

Play Console shows which device models crash. A local log helps you reproduce the problem on hardware you own or in a test session. The snippet below prints the engine version, device model, OS name and version, GPU, GPU vendor and renderer when the game starts.

Status: unexecuted. Nobody has run this code. It targets Godot 4.x and uses OS.get_model_name(), OS.get_version() and RenderingServer.get_video_adapter_name(). Check the class reference for your exact minor version before relying on it.

Save it as device_log.gd, then add it under Project Settings > Globals > Autoload:

extends Node

func _ready() -> void:
	var engine_version: String = Engine.get_version_info()["string"]
	var renderer: String = str(ProjectSettings.get_setting("rendering/renderer/rendering_method"))
	print("[device] engine=%s model=%s os=%s %s gpu=%s vendor=%s renderer=%s" % [
		engine_version,
		OS.get_model_name(),
		OS.get_name(),
		OS.get_version(),
		RenderingServer.get_video_adapter_name(),
		RenderingServer.get_video_adapter_vendor(),
		renderer
	])

Expected output (illustrative format, not a real capture): one log line such as [device] engine=4.x.x.stable.official model=<phone model> os=Android 13 gpu=<GPU name> vendor=<vendor> renderer=mobile. The values depend on the device.

Verification step: Export a debug APK, install it on a physical Android phone, and run adb logcat -s godot while you launch the game. You should see exactly one [device] line per launch. Repeat on a second device and confirm the values differ.

Failure case: If no line appears, the script is probably not registered as an autoload, or logcat is filtering the wrong tag. If model reads GenericDevice, the platform returned no model name, which is common when you run from the editor on a desktop. Verify on a real phone before drawing conclusions. Keep these logs local unless your privacy policy and Play data-safety form cover collecting them.

Step 3: Set up the campaign deliberately

Treat the table below as guidance, not tested results. Google Ads changes its interface and option names often, so check each item in your own account.

| Setting | Why it matters | What to verify | | --- | --- | --- | | Locations | Delivery follows the countries you pick, so a broad or default selection can reach places you never planned for | Only the countries you chose appear in the campaign's location list, and the location option targets people in or regularly in those places | | Languages | Your store text and in-game text should match the audience | Your listing and game support every language you select | | Bid goal and target | A target far below what the market clears at can steer delivery toward the cheapest users, not the best ones | The target comes from your own revenue per player, not from the lowest number you can type | | Daily budget | A small cap limits the cost of a mistake | You can afford to lose the entire first test with no revenue | | Device and OS requirements | They stop ads from reaching phones that cannot run the game | Min SDK and architectures match your export preset, and the Play Console device catalog matches your exclusions | | Start and end dates | A defined test window forces a review | Your calendar has a check-in during the first days, not just at the end |

The developer's write-up gives no CPI range that applies to other games, and this guide adds none. Check what Google Ads suggests for your chosen countries and compare it with your own numbers. If your game shows ads, estimate revenue per player from your ad network's dashboard once you have real players. Start from that figure, not from a hopeful install price.

Start with one or two countries where you can read the reviews and understand the language. A narrow test tells you more than a wide one, and it keeps the budget readable.

Step 4: Watch for junk signals in the first days

Do not wait for the budget to run out. Run these checks daily during the test, using your own Google Ads and Play Console data.

1. Open the Play Console statistics for installs by country and compare them with your Google Ads location list. Installs from countries you never chose mean you should stop and review your settings.
2. Check Android vitals for crash rate and ANR rate against your baseline. Play Console also publishes its own bad-behavior thresholds, so read the current definitions there.
3. Open the crash clusters and look at device models and Android versions. If most crashes sit on a few devices, exclude them in the device catalog and compare against your [device] logs.
4. Compare installs with active users. If installs climb while active users and retention stay flat, the installs are probably not real players.
5. Read your reviews and ratings. The write-up reports 5,000 downloads and only four reviews, a reminder that a large install count may say little about engagement.

Also read: filesystem mcp server in claude desktop: safe setup guide in depth

Step 5: Know when to pause

Pause the campaign when any of these happen:

1. Installs still arrive from unplanned countries after you correct the location settings.
2. Crash or ANR rate rises well above your baseline and you have not fixed the cause.
3. Installs grow but active users do not.
4. The remaining budget would only buy more of the same pattern.

Pausing costs you little, and you can restart whenever you like. A campaign that keeps running while crashes pile up costs more.

What to expect next

With a tight budget and narrow targeting, the first results will be small and noisy. Use the first days to confirm that installs come from the right places and that crashes stay near your baseline. After that, raise the budget slowly or widen the locations one change at a time, and check Play Console after each change.