কখনও, GCM মেসেজ একটি টিকল হওয়াকে বোঝায়, বা ডিভাইসে নির্দেশনা যে সার্ভারের কোথাও একটি ফ্রেশ ডাটা অপেক্ষা করছে। কিন্তু একটি GCM মেসেজ 4kb সাইজ পর্যন্ত হতে পারে তাই কখনও কখনও এটা শুধু GCM মেসেজের মধ্যে ডাটা সেন্ড করে নিজেই অর্থপূর্ন হয়, যাতে ডিভাইসকে মোটেই সার্ভারের সাথে যোগাযোগ করার প্রয়োজন না হয়। যে অবস্থায় নীচের বিৃবতিগুলি সঠিক সেই অবস্থায় এই পদ্ধতি বিবেচনা করুন:
4kb সীমার মধ্যে সকল ডাটা ফিট হবে
প্রতিটা মেসেজই গুরুত্বপূর্ন এবং সংরক্ষণ করা উচিত
একটি একক ”সার্ভারে নতুন ডাটা”টিকল এর মধ্যে মাল্টিপল GCM মেসেজ কলাপস করানো কোন মানে তৈরী করে না।
উদাহরণস্বরূপ, একটি টার্ন-বেজড নেটওয়ার্ক গেমের মধ্যে শর্ট মেসেজ বা এনকোডেড প্লেয়ার হচ্ছে একটি GCM মেসেজের মধ্যে সরাসরি ডাটা বসানোর জন্য ভালো ইউজ-কেসের উদাহরণ। ইমেইল হচ্ছে খারাপ ইউজ-কেসের একটি উদাহরণ, সেহেতু মেসেজ কখনও কখনও 4kb এর চাইতে বড় হতে পারে, এবং সার্ভারে তাদের জন্য অপেক্ষা করা ইমেইলের প্রতিটার জন্য ইউজারের একটি GCM মেসেজের প্রয়োজজন নেই।
আপনি এই পদ্ধতিও বিবেচনা করতে পারেন যখন মাল্টিকাস্ট মেসেজ সেন্ড করা হয়, সুতরাং আপনাকে ইউজার বেজ জুড়ে প্রতিটা ডিভাইসকে তাৎক্ষনিকভাবে আপডেটের জন্য আপনার সার্ভারকে হিট করতে বলতে হবে না। এই কৌশল অধিক পরিমানে ডাটা সেন্ড করার জন্য কয়েকটি কারনে উপযুক্ত নয়:
মেসেজ সহকারে একটি একক ডিভাইসকে স্প্যামিং করা থেকে বাজে বা দূর্বল কোড করা অ্যাপকে বিরত রাখতে রেট সীমা নির্দিষ্ট স্থানে আছে।
মেসেজ নির্দিষ্ট ক্রমানুসারে পৌছাবে তার কোন নিশ্চয়তা নেই
আপনি যত দ্রুত মেসেজ বাইরে পাঠিয়েছেন তা সেভাবেই পৌছাবে তার নিশ্চয়তা নেই। এমন কি যদি ডিভাইস একটি GCM মেসেজ এক সেকেন্ডে গ্রহণ করে, ম্যাক্স. 1k এ যা হচ্ছে 8kbps অথবা ১৯৯০’র দশকের প্রথম দিকে হোম ডায়াল-আপ ইন্টারনেটের গতি সম্পর্কিত। গুগল প্লেতে আপনার অ্যাপ রেটিং ইউজারের কাছে এইসব কাজগুলোকে প্রতিফলিত করবে। যখন যথাযথভাবে ব্যবহৃত হয়, সরাসরি GCM মেসেজে স্থাপিত ডাটা আপনার অ্যাপলিকেশনের অর্জিত গতিকে আরও বৃদ্ধি করতে পারে, এটাকে সার্ভারের দিকে রাউন্ড ট্রিপ কে পরিহার করতে দিয়ে।