You got the “Restricted ad serving” issue from AdMob. The detailed information is “Site Behavior: Navigation” This issue happens to your Android app. You need to fix it to remove your ad serving restriction.
1. Upgrade the AdMob SDK to the latest version.
2. Repeat requesting a review in AdMob Policy center until it is approved. Typically it takes about a week for the restriction to be removed.
Motivation: You have a Google Play application that uses AdMob for displaying ads in order to generate revenue. Google requires you to complete the data safety section. There are many options and you are not sure which options should be selected.
Solution: Select the options below and their corresponding answer.
Does your app collect or share any of the required user data types? Yes Is all of the user data collected by your app encrypted in transit? Yes Do you provide a way for users to request that their data is deleted? No
Location > Approximate location App activity > Page views and taps in app App info and performance > Crash logs, Diagnostics Device or other identifiers > Device or other identifiers
Is this data collected, shared, or both? Shared Is this data processed ephemerally? No Is this data required for your app, or can users choose whether it’s collected? Data collection is required (users can’t turn off this data collection) Why is this user data shared? Advertising or marketing
Motivation: You have an Apple developer account used to publish your applications to Apple Store Connect. However you do not want your personal name to appear as applications’ seller name. You want to change your personal name to an alias, nickname, or company name.
Solution: The only way to change your personal name to an alias, nickname, or company name is to convert your Individual developer account to an Organization developer account.
In order to do it you have to prepare the following information:
1. A legal entity (i.e. a legal organization or company).
You have some applications on App Store for sale. You want to know when you may receive your App Store revenue?
Payments are made no later than 30 days following the end of each month.
To receive payment, you must have provided all required banking and tax information and documentation, as well as meet the minimum payment threshold, ranging from US$0.02 to US$150, depending on your country or region.
If you earned more than the minimum required to trigger a payment during August, 2021, you should see that money in your bank by September, 2021 or sooner.
You went to Google Play Developer Console, then navigated to Settings > Developer account > Payments settings, then clicked on the View transactions button under the Transactions section.
Then you may have gotten a transaction with the Escheated to U.S. state or territory: DE description.
What happened? The answer is that Google had given your revenue to U.S. state governments.
What is escheatment?
Google’s answer: Companies in the U.S. are obliged to give assets that they believe are abandoned to U.S. state governments. For U.S. residents it’s the state government of the state where you’ve told us you reside. If you reside outside the U.S., then it’s our state of incorporation (Delaware). We consider an account abandoned if there’s been no activity on that account for 2-5 years (depending on your state of residence). Activity on your account means: – You signed in to your account, and – You successfully received a payment from your account.
What should I do? If your balance has been escheated to the state government, you can apply to your state government unclaimed property office to have the money returned to you. You can find your unclaimed property office by typing the name of your state together with “unclaimed property” into Google Search.
How can I avoid having my account balance escheated? If you have enough of an account balance, then make sure that you’ve met the conditions to get paid. The most common reasons for not getting a payment are: – You haven’t set up your form of payment, or – You haven’t submitted your tax information, or – You have not reached the payment threshold.
Set payment threshold to a small number so that you can get paid at least once. Then change it to any value that you want.
Programmatic advertising automates the process of buying ad space through the following technologies:
Demand-Side Platforms (DSPs): Platforms that allows you to purchase ad space through an ad exchange, like Google Ad Manager, which features advertising inventory from publishers.
Supply-Side Platforms (SSPs): Platforms that allows publishers to manage and offer ad space to advertisers, marketers, and other parties interested in purchasing ad space.
Data Management Platforms (DMP): Platforms that allows organizations to collect and manage user data for digital marketing purposes, such as programmatic advertising.
By incorporating these three technologies, as well as artificial intelligence (AI), programmatic advertising automates the process of purchasing and bidding on ad space. It also makes the process smarter, relying on user data to deliver relevant ads in milliseconds.
How does programmatic advertising work?
Let’s start by looking at an overview of the programmatic advertising process:
Arrive: Whenever a user arrives on a website involved with programmatic advertising, it triggers the automated advertising process to start. As programmatic advertising happens in milliseconds, users don’t even notice it.
Send: In response to a user arriving on a website, the website publisher automatically sends the dimensions of its ad space to an Supply-Side Platform (SSP). One way to think about this step is that the publisher lists their product for advertisers to purchase.
Read: After receiving information on the available ad space, the SSP analyzes a user’s cookies. The goal here is to learn as much as possible about the user, from their demographics to their interests, to deliver a relevant ad.
Evaluate: Next, the coordinating Demand-Side Platform (DSP) becomes involved. By reviewing the information gathered by the SSP, the DSP can evaluate the user’s worth and assign it a value — or the worth of that user’s impression.
Bid: With a value assigned to that user, the DSP submits a bid to the SSP. It’s worth noting that this process happens in real-time, which is why some refer to programmatic advertising as real-time bidding (RTB).
Choose: Once the DSP’s bid arrives, the SSP will review it and any other bids. The SSP will then pick its winner, which is often the highest bidder. Depending on the auction, you may pay your highest bid or the price of the second-highest bid, plus a fee.
Deliver: With the winner picked, the SSP delivers the ad to the user. As the programmatic advertising process happens so fast, the page will load with the ad displayed — it won’t load and then reload the page to display the ad.
Unauthorized reselling is serious problem in programmatic advertising.
When a brand advertiser buys media programmatically, they rely on the fact that the URLs they purchase were legitimately sold by those publishers. The problem is, there is currently no way for a buyer to confirm who is responsible for selling those impressions across exchanges, and there are many different scenarios when the URL passed may not be an accurate representation of what the impression actually is or who is selling it. While every impression already includes publisher information from the OpenRTB protocol, including the page URL and Publisher.ID, there is no record or information confirming who owns each Publisher.ID, nor any way to confirm the validity of the information sent in the RTB bid request, leaving the door open to counterfeit inventory.
Counterfeit impressions are created when a bad seller replaces the URL of a low-quality site with a premium publisher URL, or a fraudster creates fake impressions and labels them with a high-quality publisher’s URL. Then, the counterfeiters send their fake inventory to auction at multiple exchanges and SSPs, without the knowledge of the publishers they’re impersonating, to trick advertisers into thinking they are buying premium publisher inventory. By hiding in the digital supply chain, counterfeiters are robbing premium publishers of revenue they deserve, and tricking advertisers into buying mislabeled and potentially unsafe inventory.
Ads.txt works by creating a publicly accessible record of authorized
digital sellers for publisher inventory that programmatic buyers can
index and reference if they wish to purchase inventory from authorized
sellers. First, participating publishers must post their list of
authorized sellers to their domain. Programmatic buyers can then crawl
the web for publisher ads.txt files to create a list of authorized
sellers for each participating publisher. Then programmatic buyers can
create a filter to match their ads.txt list against the data provided in
the OpenRTB bid request.
Example: Example.com publishes ads.txt on their web server listing three exchanges as authorized to sell their inventory, including Example.com’s seller account IDs within each of those exchanges.
Note: The seller’s Publisher.ID will be specified in the “SellerAccountID” field in the ads.txt.
A buyer receiving a bid request claiming to be example.com can verify if the exchange and SellerAccountID matches the authorized sellers listed in example.com/ads.txt file.
Why should publishers implement ads.txt?
Advertisers looking to execute efficient, brand-safe programmatic campaigns should start demanding that their campaigns run only on authorised inventory, as defined by publishers’ ads.txt files, or work directly with their preferred publisher brands. If they’re not buying authorised inventory, they risk having their ads appear on counterfeit, low-quality websites, when they think they’re appearing somewhere else.