<![CDATA[Dataweb Forum - Tüm Forumlar]]> https://dataweb.com.tr/forum/ Sun, 06 Sep 2026 03:25:53 +0000 MyBB <![CDATA[Cron Job Çalışmıyor: Önce Neyi Kontrol Etmek Gerekir?]]> https://dataweb.com.tr/forum/thread-46.html Wed, 02 Sep 2026 13:07:03 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-46.html
Amaç şu üç soruyu ayrı ayrı cevaplamak:

Kod:
1. Zamanlayıcı gerçekten tetikleniyor mu? 2. PHP/script gerçekten çalışabiliyor mu? 3. Script çalışıyor ama uygulama içinde mi hata veriyor?

Aşağıdaki adımlar teknik bilmeyen birinin de sırayla uygulayabileceği şekilde hazırlanmıştır.

1) Cron gerçekten tetikleniyor mu? En basit dosya testi

Önce uygulamanızı hiç çalıştırmadan yalnız cron servisinin tetiklenip tetiklenmediğini test edin.

Yöntem A — PHP dosyasıyla test

Dosya yöneticisinde sitenizin `public_html` klasörüne girin.

Yeni bir dosya oluşturun:

Kod:
cron-test.php

İçine şunu yazın:

Kod:
<?php file_put_contents( __DIR__ . '/cron-test.log', date('Y-m-d H:i:s') . PHP_EOL, FILE_APPEND );

Kaydedin.

Şimdi hosting panelindeki Cron Jobs bölümünde geçici bir görev oluşturun.

Örneğin panel PHP türünü kendisi seçtiriyorsa:
- PHP sürümü: sitenizle aynı sürüm
- dosya: `public_html/cron-test.php`
- zamanlama: her 5 dakikada bir

Özel komut kabul ediyorsa örnek mantık:

Kod:
/usr/bin/php /home/KULLANICI/public_html/cron-test.php

Bazı hostinglerde PHP yolu farklı olabilir; aşağıdaki 2. bölümde bunu nasıl bulacağımızı anlatıyorum.

5-10 dakika bekleyin.

Dosya yöneticisini yenileyin.

Şu dosya oluşmuş olmalı:

Kod:
cron-test.log

İçini açın.

Örnek:

Kod:
2026-09-02 15:05:01 2026-09-02 15:10:01

Bu satırlar oluşuyorsa cron zamanlayıcısı çalışıyor demektir. Artık sorun cron servisinde değil, asıl scriptinizdedir.

Dosya hiç oluşmuyorsa:
- komut yanlış,
- PHP yolu yanlış,
- dosya yolu yanlış,
- cron henüz tetiklenmedi,
- panel görevi kaydetmemiş

olabilir.

Test bitince `cron-test.php` ve `cron-test.log` dosyalarını silin.

2) Panelin kullandığı PHP / CLI yolu doğru mu?

Web sitesinin PHP sürümü ile cron’un kullandığı komut satırı PHP’si aynı olmayabilir.

Örneğin web siteniz PHP 8.3 çalıştırırken cron:

Kod:
/usr/bin/php

ile PHP 8.1 çalıştırıyor olabilir.

Hostinger benzeri panellerde Cron Job oluştururken “PHP” seçeneği varsa panel çoğu zaman PHP çalıştırıcısının ilk kısmını otomatik getirir. Örneğin:

Kod:
/opt/alt/php83/usr/bin/lsphp

veya sunucuya göre:

Kod:
/usr/bin/php

görebilirsiniz.

Nereden bakılır?

Hosting paneli → Gelişmiş / Advanced → Cron Jobs / Cron Görevleri.

Mevcut cron kaydının “Komut” alanını açın.

Şuna benzer bir yapı görmelisiniz:

Kod:
PHP_YOLU /home/KULLANICI/domains/site.com/public_html/script.php

PHP yolunu ayrıca SSH erişiminiz varsa doğrulayabilirsiniz:

Kod:
php -v

ve:

Kod:
which php

Örnek çıktı:

Kod:
PHP 8.3.x (cli) /usr/bin/php

Belirli bir yolu kontrol etmek için:

Kod:
/opt/alt/php83/usr/bin/lsphp -v

veya:

Kod:
/usr/bin/php -v

SSH yoksa ne yapacağız?

Cron panelinin PHP seçeneğini kullanın. Panel PHP sürümü seçtiriyorsa elle farklı bir yol yazmak yerine önce o mekanizmayı tercih edin.

Ayrıca geçici test dosyasına:

Kod:
<?php file_put_contents( __DIR__.'/php-cron-info.txt', PHP_VERSION . ' | ' . PHP_SAPI );

yazıp cronla bir kez çalıştırabilirsiniz.

Sonra `php-cron-info.txt` içinde cron’un gördüğü PHP sürümünü okuyabilirsiniz.

Test dosyasını işiniz bitince silin.

3) Script elle çalıştırıldığında hata veriyor mu?

Cron’u devreden çıkarıp asıl PHP dosyasını manuel çalıştırmak çok değerlidir.

SSH varsa

Önce klasöre gidin:

Kod:
cd /home/KULLANICI/domains/site.com/public_html

Sonra:

Kod:
/usr/bin/php yol/script.php

veya hostingin doğru PHP yolu neyse:

Kod:
/opt/alt/php83/usr/bin/lsphp yol/script.php

Hata varsa terminalde görebilirsiniz.

Komut bittikten sonra çıkış kodunu görmek için:

Kod:
echo $?

Genelde `0` başarılı çalışmayı ifade eder; farklı değer script veya çalıştırma hatasına işaret edebilir.

SSH yoksa

Scriptiniz güvenli şekilde web üzerinden çalıştırılmak üzere tasarlanmışsa geçici olarak tarayıcıdan açılabilir. Ancak cron dosyanız yönetim işlemi yapıyorsa herkese açık bırakmayın.

Örneğin uygulamanız token destekliyorsa:

Kod:
https://site.com/cron.php?token=UZUN_GIZLI_TOKEN

gibi korumalı bir test kullanılabilir.

Token veya oturum kontrolü olmayan hassas cron dosyasını sırf test için herkese açık hale getirmeyin.

4) Çalışma dizini yüzünden relative path kırılıyor mu?

Web üzerinden çalışan kod:

Kod:
require 'app/bootstrap.php';

ile çalışırken cron farklı klasörden başlatıldığında dosyayı bulamayabilir.

Daha güvenli yaklaşım:

Kod:
require __DIR__ . '/app/bootstrap.php';

veya dosya alt klasördeyse:

Kod:
require dirname(__DIR__) . '/app/bootstrap.php';

Yani mümkün olduğunca `__DIR__` kullanın.

Alternatif olarak cron komutunda önce klasöre geçebilirsiniz:

Kod:
cd /home/KULLANICI/domains/site.com/public_html && /usr/bin/php yonetim/cron.php

5) Hata çıktısını log dosyasına nasıl yazdırırım?

Cron paneli çıktıyı göstermiyorsa stdout ve stderr’i dosyaya yönlendirin.

Örnek:

Kod:
/usr/bin/php /home/KULLANICI/public_html/cron.php >> /home/KULLANICI/cron-debug.log 2>&1

Buradaki:

Kod:
>>

çıktıyı dosyanın sonuna ekler.

Kod:
2>&1

hata çıktısını da aynı dosyaya gönderir.

Tarih de görmek istiyorsanız:

Kod:
date >> /home/KULLANICI/cron-debug.log /usr/bin/php /home/KULLANICI/public_html/cron.php >> /home/KULLANICI/cron-debug.log 2>&1

Ancak hosting panelinde komut uzunluğu sınırı olabilir. Böyle durumda ayrı bir shell wrapper veya PHP içi loglama tercih edilir.

6) PHP error log nereden kontrol edilir?

Hosting panelinde şu isimleri arayın:

- Error Logs
- PHP Errors
- Logs
- Hata Günlükleri

Dosya yöneticisinde de şu dosyalar bulunabilir:

Kod:
error_log php_error.log logs/

Hata zamanını cron’un çalışması gereken saatle karşılaştırın.

Örneğin:

Kod:
PHP Fatal error: Uncaught mysqli_sql_exception...

gibi bir kayıt varsa cron tetikleniyor fakat uygulama veritabanında çöküyor olabilir.

7) Veritabanı bağlantısı neden cron’da farklı davranabilir?

Web request ile CLI aynı ortam değildir.

Kontrol edin:

- `.env` veya config dosyası doğru yükleniyor mu?
- dosya yolu relative mı?
- DB host `localhost` mı farklı socket mi kullanıyor?
- CLI kullanıcısının gerekli dosyalara erişimi var mı?
- hosting güvenlik politikası CLI bağlantısını sınırlıyor mu?

Basit test için uygulamanızın bootstrap dosyasını yükleyip:

Kod:
SELECT 1

sorgusu çalıştıran geçici tanı sayfası hazırlanabilir.

Üretim verisini değiştirmeyen salt-okunur test tercih edin.

8) Kilit dosyası takılı kaldı mı?

Aynı cron’un iki kez paralel çalışmasını önlemek için bazı scriptler lock file kullanır.

Örnek:

Kod:
app/cron.lock storage/cron.lock /tmp/myapp-cron.lock

Script başında kilit alınıyor ama hata sonrası bırakılmıyorsa sonraki tüm çağrılar “zaten çalışıyor” sanabilir.

Kodu kontrol edin:
- lock ne zaman oluşturuluyor?
- `finally` içinde bırakılıyor mu?
- eski lock için timeout var mı?

Kilit dosyasını ne olduğunu bilmeden silmeyin. Önce scriptin gerçekten çalışmadığını doğrulayın.

9) Cron’un kendisi uzun sürüyor veya timeout oluyor olabilir mi?

Cron işi:
- büyük API çağrısı,
- çok sayıda veritabanı kaydı,
- dış web taraması

yapıyorsa çalışma süresi uzayabilir.

Script içine aşama logları ekleyin:

Kod:
[15:00:01] started [15:00:02] database ok [15:00:04] api request started [15:00:30] api request completed [15:00:31] finished

Log son olarak “api request started” satırında kalıyorsa sorunun hangi aşamada olduğunu anlarsınız.

10) Cron panelindeki boş çıktı ne anlama gelir?

Boş ekran = kesinlikle “çalışmadı” değildir.

Script:
- hiç echo üretmiyor olabilir,
- çıktıyı log dosyasına yönlendiriyor olabilir,
- başarılı çalışıp sessiz bitiyor olabilir.

Bu nedenle asıl kanıt:
- heartbeat zamanı,
- log satırı,
- veritabanındaki son çalışma kaydı,
- oluşturulan test dosyası

gibi gözlemlenebilir bir sonuçtur.

11) Yeni başlayanlar için net teşhis sırası

Aşağıdaki sırayı bozmayın:

  1. Basit `cron-test.php` ile tetikleme var mı?
  2. Cron’un kullandığı PHP sürümü doğru mu?
  3. Asıl script manuel çalışıyor mu?
  4. Absolute path / `__DIR__` kullanılıyor mu?
  5. Hata logu var mı?
  6. Veritabanı bağlantısı çalışıyor mu?
  7. Lock takılı mı?
  8. Uzun işlem/timeout var mı?

12) Destek ekibine ne göndermeliyim?

“Cron çalışmıyor” demek yerine şu bilgileri gönderin:

Kod:
Zamanlama: */15 * * * * Komut: PHP_YOLU /home/.../cron.php PHP sürümü: 8.3 Basit tarih testi: çalışıyor / çalışmıyor Manuel çalıştırma: başarılı / hata mesajı Son log: ... Son başarılı çalışma: ...

Bu bilgiler sorunu çok daha hızlı daraltır.

Güvenlik uyarısı

Cron URL’nizde token varsa ekran görüntüsünde veya forum mesajında token’ın tamamını paylaşmayın. Şifre, veritabanı parolası, API anahtarı ve tam erişim tokenlarını mutlaka gizleyin.

Sizde cron sorunu varsa ilk olarak 1. adımdaki `cron-test.php` testini yapın. Log dosyası oluşuyor mu, oluşmuyorsa paneldeki komutun yapısı nasıl? Gizli bilgileri kapatarak paylaşabilirsiniz.

Dataweb editoryal sürüm: derin anlatım v1.0.0]]>
Amaç şu üç soruyu ayrı ayrı cevaplamak:

Kod:
1. Zamanlayıcı gerçekten tetikleniyor mu? 2. PHP/script gerçekten çalışabiliyor mu? 3. Script çalışıyor ama uygulama içinde mi hata veriyor?

Aşağıdaki adımlar teknik bilmeyen birinin de sırayla uygulayabileceği şekilde hazırlanmıştır.

1) Cron gerçekten tetikleniyor mu? En basit dosya testi

Önce uygulamanızı hiç çalıştırmadan yalnız cron servisinin tetiklenip tetiklenmediğini test edin.

Yöntem A — PHP dosyasıyla test

Dosya yöneticisinde sitenizin `public_html` klasörüne girin.

Yeni bir dosya oluşturun:

Kod:
cron-test.php

İçine şunu yazın:

Kod:
<?php file_put_contents( __DIR__ . '/cron-test.log', date('Y-m-d H:i:s') . PHP_EOL, FILE_APPEND );

Kaydedin.

Şimdi hosting panelindeki Cron Jobs bölümünde geçici bir görev oluşturun.

Örneğin panel PHP türünü kendisi seçtiriyorsa:
- PHP sürümü: sitenizle aynı sürüm
- dosya: `public_html/cron-test.php`
- zamanlama: her 5 dakikada bir

Özel komut kabul ediyorsa örnek mantık:

Kod:
/usr/bin/php /home/KULLANICI/public_html/cron-test.php

Bazı hostinglerde PHP yolu farklı olabilir; aşağıdaki 2. bölümde bunu nasıl bulacağımızı anlatıyorum.

5-10 dakika bekleyin.

Dosya yöneticisini yenileyin.

Şu dosya oluşmuş olmalı:

Kod:
cron-test.log

İçini açın.

Örnek:

Kod:
2026-09-02 15:05:01 2026-09-02 15:10:01

Bu satırlar oluşuyorsa cron zamanlayıcısı çalışıyor demektir. Artık sorun cron servisinde değil, asıl scriptinizdedir.

Dosya hiç oluşmuyorsa:
- komut yanlış,
- PHP yolu yanlış,
- dosya yolu yanlış,
- cron henüz tetiklenmedi,
- panel görevi kaydetmemiş

olabilir.

Test bitince `cron-test.php` ve `cron-test.log` dosyalarını silin.

2) Panelin kullandığı PHP / CLI yolu doğru mu?

Web sitesinin PHP sürümü ile cron’un kullandığı komut satırı PHP’si aynı olmayabilir.

Örneğin web siteniz PHP 8.3 çalıştırırken cron:

Kod:
/usr/bin/php

ile PHP 8.1 çalıştırıyor olabilir.

Hostinger benzeri panellerde Cron Job oluştururken “PHP” seçeneği varsa panel çoğu zaman PHP çalıştırıcısının ilk kısmını otomatik getirir. Örneğin:

Kod:
/opt/alt/php83/usr/bin/lsphp

veya sunucuya göre:

Kod:
/usr/bin/php

görebilirsiniz.

Nereden bakılır?

Hosting paneli → Gelişmiş / Advanced → Cron Jobs / Cron Görevleri.

Mevcut cron kaydının “Komut” alanını açın.

Şuna benzer bir yapı görmelisiniz:

Kod:
PHP_YOLU /home/KULLANICI/domains/site.com/public_html/script.php

PHP yolunu ayrıca SSH erişiminiz varsa doğrulayabilirsiniz:

Kod:
php -v

ve:

Kod:
which php

Örnek çıktı:

Kod:
PHP 8.3.x (cli) /usr/bin/php

Belirli bir yolu kontrol etmek için:

Kod:
/opt/alt/php83/usr/bin/lsphp -v

veya:

Kod:
/usr/bin/php -v

SSH yoksa ne yapacağız?

Cron panelinin PHP seçeneğini kullanın. Panel PHP sürümü seçtiriyorsa elle farklı bir yol yazmak yerine önce o mekanizmayı tercih edin.

Ayrıca geçici test dosyasına:

Kod:
<?php file_put_contents( __DIR__.'/php-cron-info.txt', PHP_VERSION . ' | ' . PHP_SAPI );

yazıp cronla bir kez çalıştırabilirsiniz.

Sonra `php-cron-info.txt` içinde cron’un gördüğü PHP sürümünü okuyabilirsiniz.

Test dosyasını işiniz bitince silin.

3) Script elle çalıştırıldığında hata veriyor mu?

Cron’u devreden çıkarıp asıl PHP dosyasını manuel çalıştırmak çok değerlidir.

SSH varsa

Önce klasöre gidin:

Kod:
cd /home/KULLANICI/domains/site.com/public_html

Sonra:

Kod:
/usr/bin/php yol/script.php

veya hostingin doğru PHP yolu neyse:

Kod:
/opt/alt/php83/usr/bin/lsphp yol/script.php

Hata varsa terminalde görebilirsiniz.

Komut bittikten sonra çıkış kodunu görmek için:

Kod:
echo $?

Genelde `0` başarılı çalışmayı ifade eder; farklı değer script veya çalıştırma hatasına işaret edebilir.

SSH yoksa

Scriptiniz güvenli şekilde web üzerinden çalıştırılmak üzere tasarlanmışsa geçici olarak tarayıcıdan açılabilir. Ancak cron dosyanız yönetim işlemi yapıyorsa herkese açık bırakmayın.

Örneğin uygulamanız token destekliyorsa:

Kod:
https://site.com/cron.php?token=UZUN_GIZLI_TOKEN

gibi korumalı bir test kullanılabilir.

Token veya oturum kontrolü olmayan hassas cron dosyasını sırf test için herkese açık hale getirmeyin.

4) Çalışma dizini yüzünden relative path kırılıyor mu?

Web üzerinden çalışan kod:

Kod:
require 'app/bootstrap.php';

ile çalışırken cron farklı klasörden başlatıldığında dosyayı bulamayabilir.

Daha güvenli yaklaşım:

Kod:
require __DIR__ . '/app/bootstrap.php';

veya dosya alt klasördeyse:

Kod:
require dirname(__DIR__) . '/app/bootstrap.php';

Yani mümkün olduğunca `__DIR__` kullanın.

Alternatif olarak cron komutunda önce klasöre geçebilirsiniz:

Kod:
cd /home/KULLANICI/domains/site.com/public_html && /usr/bin/php yonetim/cron.php

5) Hata çıktısını log dosyasına nasıl yazdırırım?

Cron paneli çıktıyı göstermiyorsa stdout ve stderr’i dosyaya yönlendirin.

Örnek:

Kod:
/usr/bin/php /home/KULLANICI/public_html/cron.php >> /home/KULLANICI/cron-debug.log 2>&1

Buradaki:

Kod:
>>

çıktıyı dosyanın sonuna ekler.

Kod:
2>&1

hata çıktısını da aynı dosyaya gönderir.

Tarih de görmek istiyorsanız:

Kod:
date >> /home/KULLANICI/cron-debug.log /usr/bin/php /home/KULLANICI/public_html/cron.php >> /home/KULLANICI/cron-debug.log 2>&1

Ancak hosting panelinde komut uzunluğu sınırı olabilir. Böyle durumda ayrı bir shell wrapper veya PHP içi loglama tercih edilir.

6) PHP error log nereden kontrol edilir?

Hosting panelinde şu isimleri arayın:

- Error Logs
- PHP Errors
- Logs
- Hata Günlükleri

Dosya yöneticisinde de şu dosyalar bulunabilir:

Kod:
error_log php_error.log logs/

Hata zamanını cron’un çalışması gereken saatle karşılaştırın.

Örneğin:

Kod:
PHP Fatal error: Uncaught mysqli_sql_exception...

gibi bir kayıt varsa cron tetikleniyor fakat uygulama veritabanında çöküyor olabilir.

7) Veritabanı bağlantısı neden cron’da farklı davranabilir?

Web request ile CLI aynı ortam değildir.

Kontrol edin:

- `.env` veya config dosyası doğru yükleniyor mu?
- dosya yolu relative mı?
- DB host `localhost` mı farklı socket mi kullanıyor?
- CLI kullanıcısının gerekli dosyalara erişimi var mı?
- hosting güvenlik politikası CLI bağlantısını sınırlıyor mu?

Basit test için uygulamanızın bootstrap dosyasını yükleyip:

Kod:
SELECT 1

sorgusu çalıştıran geçici tanı sayfası hazırlanabilir.

Üretim verisini değiştirmeyen salt-okunur test tercih edin.

8) Kilit dosyası takılı kaldı mı?

Aynı cron’un iki kez paralel çalışmasını önlemek için bazı scriptler lock file kullanır.

Örnek:

Kod:
app/cron.lock storage/cron.lock /tmp/myapp-cron.lock

Script başında kilit alınıyor ama hata sonrası bırakılmıyorsa sonraki tüm çağrılar “zaten çalışıyor” sanabilir.

Kodu kontrol edin:
- lock ne zaman oluşturuluyor?
- `finally` içinde bırakılıyor mu?
- eski lock için timeout var mı?

Kilit dosyasını ne olduğunu bilmeden silmeyin. Önce scriptin gerçekten çalışmadığını doğrulayın.

9) Cron’un kendisi uzun sürüyor veya timeout oluyor olabilir mi?

Cron işi:
- büyük API çağrısı,
- çok sayıda veritabanı kaydı,
- dış web taraması

yapıyorsa çalışma süresi uzayabilir.

Script içine aşama logları ekleyin:

Kod:
[15:00:01] started [15:00:02] database ok [15:00:04] api request started [15:00:30] api request completed [15:00:31] finished

Log son olarak “api request started” satırında kalıyorsa sorunun hangi aşamada olduğunu anlarsınız.

10) Cron panelindeki boş çıktı ne anlama gelir?

Boş ekran = kesinlikle “çalışmadı” değildir.

Script:
- hiç echo üretmiyor olabilir,
- çıktıyı log dosyasına yönlendiriyor olabilir,
- başarılı çalışıp sessiz bitiyor olabilir.

Bu nedenle asıl kanıt:
- heartbeat zamanı,
- log satırı,
- veritabanındaki son çalışma kaydı,
- oluşturulan test dosyası

gibi gözlemlenebilir bir sonuçtur.

11) Yeni başlayanlar için net teşhis sırası

Aşağıdaki sırayı bozmayın:

  1. Basit `cron-test.php` ile tetikleme var mı?
  2. Cron’un kullandığı PHP sürümü doğru mu?
  3. Asıl script manuel çalışıyor mu?
  4. Absolute path / `__DIR__` kullanılıyor mu?
  5. Hata logu var mı?
  6. Veritabanı bağlantısı çalışıyor mu?
  7. Lock takılı mı?
  8. Uzun işlem/timeout var mı?

12) Destek ekibine ne göndermeliyim?

“Cron çalışmıyor” demek yerine şu bilgileri gönderin:

Kod:
Zamanlama: */15 * * * * Komut: PHP_YOLU /home/.../cron.php PHP sürümü: 8.3 Basit tarih testi: çalışıyor / çalışmıyor Manuel çalıştırma: başarılı / hata mesajı Son log: ... Son başarılı çalışma: ...

Bu bilgiler sorunu çok daha hızlı daraltır.

Güvenlik uyarısı

Cron URL’nizde token varsa ekran görüntüsünde veya forum mesajında token’ın tamamını paylaşmayın. Şifre, veritabanı parolası, API anahtarı ve tam erişim tokenlarını mutlaka gizleyin.

Sizde cron sorunu varsa ilk olarak 1. adımdaki `cron-test.php` testini yapın. Log dosyası oluşuyor mu, oluşmuyorsa paneldeki komutun yapısı nasıl? Gizli bilgileri kapatarak paylaşabilirsiniz.

Dataweb editoryal sürüm: derin anlatım v1.0.0]]> <![CDATA[Pazaryerinde Başabaş Satış Fiyatı Nasıl Hesaplanır?]]> https://dataweb.com.tr/forum/thread-45.html Wed, 02 Sep 2026 13:07:03 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-45.html
Bu yüzden fiyat belirlerken önce başabaş seviyeyi, sonra hedef kârı hesaplamak daha sağlıklıdır.

1) Önce bütün sipariş maliyetlerini ayrı ayrı yazın

Bir ürün için tablo açın:

Kod:
Ürün maliyeti Kargo Reklam / sipariş Hizmet / işlem bedeli Paketleme Diğer sabit sipariş giderleri Komisyon oranı

Önemli ayrım:
Komisyon genellikle satış fiyatına bağlı yüzdesel giderdir.
Diğerlerinin bir kısmı sipariş başına sabit olabilir.

2) Basitleştirilmiş başabaş formülü

Komisyon satış fiyatının yüzdesiyse:

Kod:
Başabaş Satış Fiyatı = Sabit Sipariş Maliyetleri / (1 - Komisyon Oranı)

Örnek:

Kod:
Ürün maliyeti: 450 TL Kargo: 70 TL Reklam: 50 TL Hizmet bedeli: 20 TL Toplam sabit maliyet: 590 TL Komisyon: %20

Hesap:

Kod:
590 / (1 - 0,20) 590 / 0,80 = 737,50 TL

Yani girilen varsayımlarla yaklaşık 737,50 TL satış fiyatı başabaş seviyedir.

Kendi ürününüz için:
Pazaryeri Komisyon Hesaplama Aracı

3) Neden “maliyet + %20” hesabı yanlış çıkabilir?

Ürün maliyeti 450 TL olsun.

450 + %20 = 540 TL satış fiyatı yaptığınızda komisyon da 540 TL üzerinden kesilir. Üstelik kargo ve diğer giderler hâlâ duruyor.

Yani maliyetin üzerine eklediğiniz yüzde, doğrudan cebinizde kalan kâr yüzdesi değildir.

4) Satıcıya kalan ile gerçek katkıyı ayırın

Örneğin:

Kod:
Satış: 1.000 TL Komisyon: 200 TL Kargo: 70 TL Reklam: 50 TL Hizmet: 20 TL

Pazaryeri/operasyon kesintilerinden sonra:

Kod:
1.000 - 200 - 70 - 50 - 20 = 660 TL

Bu 660 TL “satıcıya kalan” gibi düşünülebilir.

Ama ürün maliyeti 450 TL ise:

Kod:
660 - 450 = 210 TL

yaklaşık ürün katkısı kalır.

Yani “hesabıma 660 TL geçti” ile “660 TL kazandım” aynı şey değildir.

5) Katkı marjı nasıl bulunur?

Kod:
Katkı Marjı = Ürün Katkısı / Satış Fiyatı

210 TL katkı ve 1.000 TL satışta:

Kod:
210 / 1.000 = %21

Ama bu da net şirket kârı değildir. Genel gider, personel, yazılım, kira, vergi ve finansman giderleri ayrıca olabilir.

6) Reklam maliyetini ürün başına nasıl dağıtmalı?

Bir ayda:

Kod:
Toplam reklam: 30.000 TL Reklamdan gelen sipariş: 600

ise kaba ortalama:

Kod:
30.000 / 600 = 50 TL / sipariş

olur.

Ama farklı ürünlerin reklam maliyeti ciddi biçimde değişiyorsa ürün/kampanya bazında ayrı takip daha doğrudur.

7) İade maliyetini nasıl hesaba katmalı?

Her sipariş iade olmuyor. Bu nedenle tek ürüne rastgele tam iade maliyeti yazmak yerine dönemsel ortalama kullanılabilir.

Örneğin:
- 1.000 sipariş
- 80 iade
- toplam iade kaynaklı ek maliyet 24.000 TL

ise:

Kod:
24.000 / 1.000 = 24 TL ortalama iade maliyeti / sipariş

gibi bir dağıtım yapılabilir.

8) Kampanya ve kuponlar neden tehlikeli?

“%10 indirim yaptım, satış arttı” iyi görünebilir. Ama şu üçü aynı anda düşebilir:

- satış fiyatı
- komisyon sonrası kalan
- katkı marjı

Kampanya öncesi ve sonrası aynı maliyet tablosunu kullanarak iki ayrı senaryo hesaplayın.

9) Başabaş fiyatın üstüne ne kadar eklenmeli?

Bu, hedef katkı marjınıza bağlıdır.

Örneğin yalnız “zarar etmeyeyim” hedefi başka, ürün başına %15 katkı bırakmak başka fiyat gerektirir.

Bu nedenle fiyatlama tablosuna şu sütunu da ekleyin:

Kod:
Hedef katkı TL Hedef katkı %

Sonra rakip fiyatıyla değil, kendi ekonomik sınırınızla karşılaştırın.

10) Ürün çok satıyor ama neden para bırakmıyor?

En sık nedenler:

- komisyon oranı yüksek
- kargo yanlış hesaplanmış
- reklam maliyeti siparişe dağıtılmamış
- iadeler hesaba katılmamış
- kampanya indirimi katkıyı eritmiş
- düşük fiyat nedeniyle hacim artarken marj sıfırlanmış
- hizmet/işlem bedelleri gözden kaçmış

11) Aylık ürün kârlılık tablosu

Her SKU için:

Kod:
Satış adedi Brüt satış Komisyon Kargo Reklam İade Hizmet bedeli Ürün maliyeti Katkı TL Katkı %

tutarsanız çok satan ama zarar ettiren ürünü daha kolay yakalarsınız.

Konuyu daha geniş ele alan rehber:
Pazaryeri komisyonu nasıl hesaplanır? Gerçek kârlılık rehberi

Siz ürün fiyatını belirlerken en çok hangi gideri gözden kaçırıyorsunuz: reklam, kargo, komisyon, iade yoksa kampanya maliyeti mi?

Dataweb editoryal sürüm: derin anlatım v1.0.0]]>
Bu yüzden fiyat belirlerken önce başabaş seviyeyi, sonra hedef kârı hesaplamak daha sağlıklıdır.

1) Önce bütün sipariş maliyetlerini ayrı ayrı yazın

Bir ürün için tablo açın:

Kod:
Ürün maliyeti Kargo Reklam / sipariş Hizmet / işlem bedeli Paketleme Diğer sabit sipariş giderleri Komisyon oranı

Önemli ayrım:
Komisyon genellikle satış fiyatına bağlı yüzdesel giderdir.
Diğerlerinin bir kısmı sipariş başına sabit olabilir.

2) Basitleştirilmiş başabaş formülü

Komisyon satış fiyatının yüzdesiyse:

Kod:
Başabaş Satış Fiyatı = Sabit Sipariş Maliyetleri / (1 - Komisyon Oranı)

Örnek:

Kod:
Ürün maliyeti: 450 TL Kargo: 70 TL Reklam: 50 TL Hizmet bedeli: 20 TL Toplam sabit maliyet: 590 TL Komisyon: %20

Hesap:

Kod:
590 / (1 - 0,20) 590 / 0,80 = 737,50 TL

Yani girilen varsayımlarla yaklaşık 737,50 TL satış fiyatı başabaş seviyedir.

Kendi ürününüz için:
Pazaryeri Komisyon Hesaplama Aracı

3) Neden “maliyet + %20” hesabı yanlış çıkabilir?

Ürün maliyeti 450 TL olsun.

450 + %20 = 540 TL satış fiyatı yaptığınızda komisyon da 540 TL üzerinden kesilir. Üstelik kargo ve diğer giderler hâlâ duruyor.

Yani maliyetin üzerine eklediğiniz yüzde, doğrudan cebinizde kalan kâr yüzdesi değildir.

4) Satıcıya kalan ile gerçek katkıyı ayırın

Örneğin:

Kod:
Satış: 1.000 TL Komisyon: 200 TL Kargo: 70 TL Reklam: 50 TL Hizmet: 20 TL

Pazaryeri/operasyon kesintilerinden sonra:

Kod:
1.000 - 200 - 70 - 50 - 20 = 660 TL

Bu 660 TL “satıcıya kalan” gibi düşünülebilir.

Ama ürün maliyeti 450 TL ise:

Kod:
660 - 450 = 210 TL

yaklaşık ürün katkısı kalır.

Yani “hesabıma 660 TL geçti” ile “660 TL kazandım” aynı şey değildir.

5) Katkı marjı nasıl bulunur?

Kod:
Katkı Marjı = Ürün Katkısı / Satış Fiyatı

210 TL katkı ve 1.000 TL satışta:

Kod:
210 / 1.000 = %21

Ama bu da net şirket kârı değildir. Genel gider, personel, yazılım, kira, vergi ve finansman giderleri ayrıca olabilir.

6) Reklam maliyetini ürün başına nasıl dağıtmalı?

Bir ayda:

Kod:
Toplam reklam: 30.000 TL Reklamdan gelen sipariş: 600

ise kaba ortalama:

Kod:
30.000 / 600 = 50 TL / sipariş

olur.

Ama farklı ürünlerin reklam maliyeti ciddi biçimde değişiyorsa ürün/kampanya bazında ayrı takip daha doğrudur.

7) İade maliyetini nasıl hesaba katmalı?

Her sipariş iade olmuyor. Bu nedenle tek ürüne rastgele tam iade maliyeti yazmak yerine dönemsel ortalama kullanılabilir.

Örneğin:
- 1.000 sipariş
- 80 iade
- toplam iade kaynaklı ek maliyet 24.000 TL

ise:

Kod:
24.000 / 1.000 = 24 TL ortalama iade maliyeti / sipariş

gibi bir dağıtım yapılabilir.

8) Kampanya ve kuponlar neden tehlikeli?

“%10 indirim yaptım, satış arttı” iyi görünebilir. Ama şu üçü aynı anda düşebilir:

- satış fiyatı
- komisyon sonrası kalan
- katkı marjı

Kampanya öncesi ve sonrası aynı maliyet tablosunu kullanarak iki ayrı senaryo hesaplayın.

9) Başabaş fiyatın üstüne ne kadar eklenmeli?

Bu, hedef katkı marjınıza bağlıdır.

Örneğin yalnız “zarar etmeyeyim” hedefi başka, ürün başına %15 katkı bırakmak başka fiyat gerektirir.

Bu nedenle fiyatlama tablosuna şu sütunu da ekleyin:

Kod:
Hedef katkı TL Hedef katkı %

Sonra rakip fiyatıyla değil, kendi ekonomik sınırınızla karşılaştırın.

10) Ürün çok satıyor ama neden para bırakmıyor?

En sık nedenler:

- komisyon oranı yüksek
- kargo yanlış hesaplanmış
- reklam maliyeti siparişe dağıtılmamış
- iadeler hesaba katılmamış
- kampanya indirimi katkıyı eritmiş
- düşük fiyat nedeniyle hacim artarken marj sıfırlanmış
- hizmet/işlem bedelleri gözden kaçmış

11) Aylık ürün kârlılık tablosu

Her SKU için:

Kod:
Satış adedi Brüt satış Komisyon Kargo Reklam İade Hizmet bedeli Ürün maliyeti Katkı TL Katkı %

tutarsanız çok satan ama zarar ettiren ürünü daha kolay yakalarsınız.

Konuyu daha geniş ele alan rehber:
Pazaryeri komisyonu nasıl hesaplanır? Gerçek kârlılık rehberi

Siz ürün fiyatını belirlerken en çok hangi gideri gözden kaçırıyorsunuz: reklam, kargo, komisyon, iade yoksa kampanya maliyeti mi?

Dataweb editoryal sürüm: derin anlatım v1.0.0]]> <![CDATA[Canonical mı 301 Yönlendirme mi? Parametreli URL'lerde Hangisi Kullanılmalı?]]> https://dataweb.com.tr/forum/thread-44.html Wed, 02 Sep 2026 13:07:03 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-44.html
En kısa ayrım:

Alıntı:301: Bu eski URL artık kullanılmamalı, kullanıcıyı da yeni URL’ye gönder.

Alıntı:Canonical: Bu URL kullanılabilir ama arama motoru açısından asıl sürüm şu URL olsun.

Şimdi hangi durumda hangisini kullanacağınızı adım adım ayıralım.

1) 301 yönlendirme nedir?

Kullanıcı eski URL’ye girdiğinde tarayıcı otomatik olarak yeni URL’ye gider.

Örnek:

Kod:
/eski-hizmet ↓ 301 /yeni-hizmet

Kullanıcı eski adresi görmeye devam etmez.

301 şu senaryolarda genellikle daha uygundur:

- kalıcı slug değişikliği
- HTTP → HTTPS
- www → non-www veya tersi
- eski ürünün yeni kalıcı URL’ye taşınması
- site taşıma
- kaldırılmış ama birebir karşılığı olan sayfa

2) Canonical nedir?

Sayfa kullanıcıya açılmaya devam eder. Ancak HTML kaynak kodunda Google’a tercih edilen sürüm bildirilir.

Örnek:

Kod:
https://site.com/kategori?sort=fiyat

sayfası çalışmaya devam eder ama kaynak kodu:

Kod:
<link rel="canonical" href="https://site.com/kategori">

diyebilir.

Kullanıcı fiyat sıralamasını kullanabilir; Google ise ana kategori URL’sini esas sayfa olarak değerlendirebilir.

3) Parametreli URL’lerde neden her zaman 301 kullanamıyoruz?

Bir e-ticaret veya forum düşünün.

Kullanıcı:
- fiyata göre sıralama,
- tarihe göre sıralama,
- artan/azalan sıralama,
- filtre

seçiyor.

Eğer tüm parametreli URL’leri 301 ile ana sayfaya atarsanız kullanıcı seçtiği görünümü kaybeder. İşlev bozulur.

Böyle bir durumda alternatif URL açık kalıp temiz URL’ye canonical vermek daha mantıklı olabilir.

4) Forumlarda sık görülen örnekler

MyBB ve benzeri forumlarda şu tür adresler oluşabilir:

Kod:
thread-12-lastpost.html thread-12-newpost.html thread-12-post-45.html forumdisplay.php?fid=16 /forum/seo?sortby=replies&order=desc

Bunların hepsi yeni ve bağımsız içerik olmak zorunda değildir.

Örneğin:
- “lastpost” kullanıcıyı son mesaja götürür,
- “post-45” belirli bir mesaja odaklanır,
- sıralama URL’si aynı konu listesini farklı düzende gösterir.

Burada kullanıcı işlevini koruyup temiz konu/kategori URL’sini canonical seçmek mantıklı olabilir.

5) Bir URL tamamen eskidiyse canonical yetmez

Örneğin:

Kod:
/hizmetler/eski-seo-paketi

artık kullanılmıyor ve yeni sayfa:

Kod:
/hizmetler/seo-danismanligi

ise eski sayfayı açık bırakıp yalnız canonical vermek yerine gerçekten kalıcı taşındıysa 301 daha temizdir.

6) “Canonical verdim, Google kesin bunu seçer mi?”

Canonical güçlü bir sinyaldir ama arama motorları sayfadaki diğer sinyalleri de değerlendirir.

Bu nedenle:
- sitemap,
- iç bağlantılar,
- hreflang,
- yönlendirmeler,
- içerik benzerliği

ile canonical’ın birbiriyle çelişmemesi gerekir.

Örneğin A sayfası canonical olarak B’yi gösterirken sitemap’e yalnız A’yı koymak tutarsız bir sinyal oluşturur.

7) Karar ağacı

Şu soruları sırayla sorun:

Soru 1: Kullanıcı bu alternatif URL’yi kullanmaya devam etmeli mi?

HAYIR → 301 düşünün.
EVET → ikinci soruya geçin.

Soru 2: Sayfa esasen aynı içeriğin sıralama/filtre/alternatif görünümü mü?

EVET → canonical daha uygun olabilir.
HAYIR → üçüncü soruya geçin.

Soru 3: İçerik gerçekten ayrı arama niyetine cevap veriyor mu?

EVET → kendi canonical’ı olsun.
HAYIR → birleştirme stratejisini değerlendirin.

8) Kaynak kodunda canonical nasıl kontrol edilir?

Sayfayı açın.

Windows/Linux:
Kod:
Ctrl + U

Mac:
Kod:
Command + Option + U

Sonra:
Kod:
canonical

arayın.

Beklenen:

Kod:
<link rel="canonical" href="https://site.com/tercih-edilen-url">

9) 301 nasıl kontrol edilir?

Tarayıcıda eski URL’ye gidin ve adres çubuğunun yeni URL’ye geçtiğini gözlemleyin.

Daha teknik kontrol:

Kod:
curl -I https://site.com/eski-url

Beklenen örnek:

Kod:
HTTP/2 301 location: https://site.com/yeni-url

10) Sitemap’te hangisi olmalı?

Genel prensip:
- 301 ile yönlenen eski URL değil, hedef URL.
- canonical alternatif değil, canonical URL.

Yani sitemap arama motoruna “bunlar benim esas indexlenebilir URL’lerim” demelidir.

11) noindex ile canonical birlikte kullanılır mı?

Teknik olarak kullanılabilir ama çoğu durumda niyet karışır. “Bu sayfayı dizine alma” ile “bu içeriğin tercih edilen sürümü şu” sinyallerini aynı anda vermek yerine sayfanın amacına göre daha net bir strateji seçmek daha iyidir.

12) Pratik örnek tablosu

Kod:
Eski kalıcı URL → yeni URL 301 HTTP → HTTPS 301 www → non-www 301 Sıralama parametresi canonical Filtre URL'si duruma göre canonical/noindex Yazdırma sürümü canonical/noindex Belirli posta giden alternatif URL canonical Tamamen ayrı içerik self-canonical

Sizde karar vermekte zorlandığınız URL türü hangisi? Parametre, eski slug, filtre, sayfalama veya forum alternatifi mi?

Dataweb editoryal sürüm: derin anlatım v1.0.0]]>
En kısa ayrım:

Alıntı:301: Bu eski URL artık kullanılmamalı, kullanıcıyı da yeni URL’ye gönder.

Alıntı:Canonical: Bu URL kullanılabilir ama arama motoru açısından asıl sürüm şu URL olsun.

Şimdi hangi durumda hangisini kullanacağınızı adım adım ayıralım.

1) 301 yönlendirme nedir?

Kullanıcı eski URL’ye girdiğinde tarayıcı otomatik olarak yeni URL’ye gider.

Örnek:

Kod:
/eski-hizmet ↓ 301 /yeni-hizmet

Kullanıcı eski adresi görmeye devam etmez.

301 şu senaryolarda genellikle daha uygundur:

- kalıcı slug değişikliği
- HTTP → HTTPS
- www → non-www veya tersi
- eski ürünün yeni kalıcı URL’ye taşınması
- site taşıma
- kaldırılmış ama birebir karşılığı olan sayfa

2) Canonical nedir?

Sayfa kullanıcıya açılmaya devam eder. Ancak HTML kaynak kodunda Google’a tercih edilen sürüm bildirilir.

Örnek:

Kod:
https://site.com/kategori?sort=fiyat

sayfası çalışmaya devam eder ama kaynak kodu:

Kod:
<link rel="canonical" href="https://site.com/kategori">

diyebilir.

Kullanıcı fiyat sıralamasını kullanabilir; Google ise ana kategori URL’sini esas sayfa olarak değerlendirebilir.

3) Parametreli URL’lerde neden her zaman 301 kullanamıyoruz?

Bir e-ticaret veya forum düşünün.

Kullanıcı:
- fiyata göre sıralama,
- tarihe göre sıralama,
- artan/azalan sıralama,
- filtre

seçiyor.

Eğer tüm parametreli URL’leri 301 ile ana sayfaya atarsanız kullanıcı seçtiği görünümü kaybeder. İşlev bozulur.

Böyle bir durumda alternatif URL açık kalıp temiz URL’ye canonical vermek daha mantıklı olabilir.

4) Forumlarda sık görülen örnekler

MyBB ve benzeri forumlarda şu tür adresler oluşabilir:

Kod:
thread-12-lastpost.html thread-12-newpost.html thread-12-post-45.html forumdisplay.php?fid=16 /forum/seo?sortby=replies&order=desc

Bunların hepsi yeni ve bağımsız içerik olmak zorunda değildir.

Örneğin:
- “lastpost” kullanıcıyı son mesaja götürür,
- “post-45” belirli bir mesaja odaklanır,
- sıralama URL’si aynı konu listesini farklı düzende gösterir.

Burada kullanıcı işlevini koruyup temiz konu/kategori URL’sini canonical seçmek mantıklı olabilir.

5) Bir URL tamamen eskidiyse canonical yetmez

Örneğin:

Kod:
/hizmetler/eski-seo-paketi

artık kullanılmıyor ve yeni sayfa:

Kod:
/hizmetler/seo-danismanligi

ise eski sayfayı açık bırakıp yalnız canonical vermek yerine gerçekten kalıcı taşındıysa 301 daha temizdir.

6) “Canonical verdim, Google kesin bunu seçer mi?”

Canonical güçlü bir sinyaldir ama arama motorları sayfadaki diğer sinyalleri de değerlendirir.

Bu nedenle:
- sitemap,
- iç bağlantılar,
- hreflang,
- yönlendirmeler,
- içerik benzerliği

ile canonical’ın birbiriyle çelişmemesi gerekir.

Örneğin A sayfası canonical olarak B’yi gösterirken sitemap’e yalnız A’yı koymak tutarsız bir sinyal oluşturur.

7) Karar ağacı

Şu soruları sırayla sorun:

Soru 1: Kullanıcı bu alternatif URL’yi kullanmaya devam etmeli mi?

HAYIR → 301 düşünün.
EVET → ikinci soruya geçin.

Soru 2: Sayfa esasen aynı içeriğin sıralama/filtre/alternatif görünümü mü?

EVET → canonical daha uygun olabilir.
HAYIR → üçüncü soruya geçin.

Soru 3: İçerik gerçekten ayrı arama niyetine cevap veriyor mu?

EVET → kendi canonical’ı olsun.
HAYIR → birleştirme stratejisini değerlendirin.

8) Kaynak kodunda canonical nasıl kontrol edilir?

Sayfayı açın.

Windows/Linux:
Kod:
Ctrl + U

Mac:
Kod:
Command + Option + U

Sonra:
Kod:
canonical

arayın.

Beklenen:

Kod:
<link rel="canonical" href="https://site.com/tercih-edilen-url">

9) 301 nasıl kontrol edilir?

Tarayıcıda eski URL’ye gidin ve adres çubuğunun yeni URL’ye geçtiğini gözlemleyin.

Daha teknik kontrol:

Kod:
curl -I https://site.com/eski-url

Beklenen örnek:

Kod:
HTTP/2 301 location: https://site.com/yeni-url

10) Sitemap’te hangisi olmalı?

Genel prensip:
- 301 ile yönlenen eski URL değil, hedef URL.
- canonical alternatif değil, canonical URL.

Yani sitemap arama motoruna “bunlar benim esas indexlenebilir URL’lerim” demelidir.

11) noindex ile canonical birlikte kullanılır mı?

Teknik olarak kullanılabilir ama çoğu durumda niyet karışır. “Bu sayfayı dizine alma” ile “bu içeriğin tercih edilen sürümü şu” sinyallerini aynı anda vermek yerine sayfanın amacına göre daha net bir strateji seçmek daha iyidir.

12) Pratik örnek tablosu

Kod:
Eski kalıcı URL → yeni URL 301 HTTP → HTTPS 301 www → non-www 301 Sıralama parametresi canonical Filtre URL'si duruma göre canonical/noindex Yazdırma sürümü canonical/noindex Belirli posta giden alternatif URL canonical Tamamen ayrı içerik self-canonical

Sizde karar vermekte zorlandığınız URL türü hangisi? Parametre, eski slug, filtre, sayfalama veya forum alternatifi mi?

Dataweb editoryal sürüm: derin anlatım v1.0.0]]> <![CDATA[Google Search Console'da “Tarandı - Şu Anda Dizine Eklenmedi” Nasıl Çözülür?]]> https://dataweb.com.tr/forum/thread-43.html Wed, 02 Sep 2026 13:07:03 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-43.html
Önemli olan URL’nin gerçekten dizine girmesini isteyip istemediğimizi ve Google’ın neden tereddüt etmiş olabileceğini sistematik biçimde kontrol etmektir.

1) İlk soru: Bu URL gerçekten Google’da görünmeli mi?

Önce URL’nin tipini belirleyin.

Dizine girmesini genellikle istediğimiz sayfalar:
- özgün makale/rehber
- ürün veya hizmet sayfası
- değerli kategori
- forum konusu
- hesaplama aracı

Dizine girmesini istemeyebileceğimiz sayfalar:
- yazdırma sürümü
- arama sonucu
- sıralama/filtre URL’si
- kullanıcı paneli
- giriş/kayıt
- geçici test sayfası
- RSS/Atom
- aynı içeriğin alternatif URL’si

Teknik yardımcı URL’yi zorla indexletmeye çalışmak yerine doğru canonical/noindex davranışını korumak gerekir.

2) Search Console’da URL Denetimi nasıl yapılır?

Search Console’a girin.

Üstteki “URL’leri denetleyin” alanına tam adresi yapıştırın.

Örnek:
Kod:
https://siteadi.com/ornek-sayfa/

Enter’a basın.

Karşınıza iki farklı veri türü çıkabilir:

Google Dizini: Google’ın son bildiği durum.
Canlı Test: Sayfanın şu anki teknik durumu.

Eski raporda noindex görünüp canlı testte sorun görünmemesi mümkündür. Bu durumda rapor güncellenmeyi bekliyor olabilir.

3) “Canlı URL’yi Test Et” ne zaman kullanılmalı?

Sayfada yakın zamanda değişiklik yaptıysanız kullanın.

Sağ üstte:
CANLI URL’Yİ TEST ET

butonuna basın.

Test sonunda özellikle şunlara bakın:

- URL Google tarafından kullanılabilir mi?
- Sayfa dizine eklenebilir mi?
- robots.txt izin veriyor mu?
- noindex var mı?
- sayfa başarıyla getirildi mi?

Canlı test “dizine eklenebilir” diyorsa teknik engel büyük ölçüde kalkmıştır.

4) noindex nasıl kontrol edilir?

Sayfayı tarayıcıda açın.

Windows/Linux:
Kod:
Ctrl + U

Mac:
Kod:
Command + Option + U

Kaynak kodunda arayın:

Kod:
noindex

Şuna benzer bir satır varsa:

Kod:
<meta name="robots" content="noindex,follow">

Google’ın sayfayı dizine almaması beklenir.

Ama noindex yalnız HTML meta etiketiyle gelmez. HTTP başlığında da olabilir:

Kod:
X-Robots-Tag: noindex

Bunu tarayıcı geliştirici araçları, curl veya sunucu başlık testiyle kontrol edebilirsiniz.

5) canonical nasıl kontrol edilir?

Kaynak kodunda:

Kod:
canonical

araması yapın.

Beklenen örnek:

Kod:
<link rel="canonical" href="https://siteadi.com/ornek-sayfa/">

Eğer sayfa kendi URL’si yerine başka bir URL’yi canonical gösteriyorsa Google diğer adresi esas sayfa olarak seçebilir.

Özellikle:
- filtre,
- sıralama,
- yazdırma,
- post/lastpost,
- parametreli URL

gibi alternatiflerde bu normal olabilir.

6) Sitemap kontrolü nasıl yapılır?

Search Console:
Dizin oluşturma → Site Haritaları

alanına gidin.

Sitemap başarılı mı bakın.

Sonra sitemap dosyasını tarayıcıda açıp URL’nin gerçekten listelenip listelenmediğini kontrol edin.

Önemli: sitemap’e yalnız canonical ve indexlenmesini istediğiniz URL’leri koymak daha sağlıklıdır. Parametreli kopyaları sitemap’e eklemeyin.

7) İç bağlantı var mı?

Google bir URL’yi yalnız sitemap’te görmekle yetinmez. Site içinde anlamlı bir yerden bağlantı gelmesi de önemlidir.

Kontrol edin:

- ana kategori link veriyor mu?
- ilgili rehber link veriyor mu?
- breadcrumb içinde mi?
- başka bir içerikten doğal bağlantı var mı?

“Yetim sayfa” olarak kalan içerikler daha zayıf keşfedilebilir.

8) İçerik gerçekten ayrı bir değer sunuyor mu?

“Tarandı fakat dizine eklenmedi” sorununun önemli kısmı teknik değil, içerik tarafında olabilir.

Şunları sorgulayın:

- başka bir sayfayla neredeyse aynı mı?
- sadece 3-4 cümle mi?
- başlık var ama soruyu gerçekten cevaplıyor mu?
- kullanıcı o sayfaya geldiğinde işlemini tamamlayabiliyor mu?
- otomatik üretilmiş ama fayda eklemeyen metin mi?
- aynı anahtar kelimeyi hedefleyen başka güçlü URL var mı?

Google’ın “aynı şeyi anlatan ikinci sayfa” yerine tek bir URL’yi seçmesi normaldir.

9) HTTP durum kodunu kontrol edin

Sayfa gerçekten 200 dönmeli.

301/302 ise yönlendirmeli URL’dir.
404/410 ise dizine alınmaz.
5xx ise sunucu hatası vardır.

Komut satırı erişiminiz varsa:

Kod:
curl -I https://siteadi.com/ornek-sayfa/

Windows’ta curl çoğu güncel sürümde hazır gelir. SSH yoksa çevrimiçi HTTP header kontrol araçları veya tarayıcı geliştirici araçları kullanılabilir.

10) “Dizine eklenmesini iste” ne zaman kullanılmalı?

Şu kontroller geçildikten sonra:

- URL gerçek içerik
- 200 durum kodu
- noindex yok
- canonical doğru
- sitemap doğru
- içerik yeterli
- iç bağlantı var
- canlı test dizine eklenebilir

Search Console URL Denetimi ekranında:
DİZİNE EKLENMESİNİ İSTE

butonuna bir kez basın.

Aynı URL’yi sürekli tekrar göndermek önceliğini artırmaz.

11) Sonra ne kadar beklemeli?

Sabit bir süre yoktur. Yeni veya düşük otoriteli sitelerde tarama/indexleme daha yavaş olabilir. Birkaç saat içinde de olabilir, günler veya daha uzun da sürebilir.

Tekrar kontrol ederken yalnız “index oldu mu?” değil, Search Console’daki son tarama tarihi ve canonical bilgisini de karşılaştırın.

12) Hızlı teşhis tablosu

Kod:
URL gerçek içerik mi? EVET/HAYIR HTTP 200 mü? EVET/HAYIR noindex var mı? EVET/HAYIR canonical kendisi mi? EVET/HAYIR sitemap'te var mı? EVET/HAYIR iç link var mı? EVET/HAYIR canlı test başarılı mı? EVET/HAYIR içerik özgün ve yeterli mi? EVET/HAYIR

Google Search Console’a yeni başlayanlar için:
Google Search Console ne işe yarar?

Sizde “Tarandı - şu anda dizine eklenmedi” en çok hangi sayfa tipinde çıkıyor? URL’yi paylaşmadan sayfa türünü ve canlı test sonucunu yazarsanız birlikte teşhis edebiliriz.

Dataweb editoryal sürüm: derin anlatım v1.0.0]]>
Önemli olan URL’nin gerçekten dizine girmesini isteyip istemediğimizi ve Google’ın neden tereddüt etmiş olabileceğini sistematik biçimde kontrol etmektir.

1) İlk soru: Bu URL gerçekten Google’da görünmeli mi?

Önce URL’nin tipini belirleyin.

Dizine girmesini genellikle istediğimiz sayfalar:
- özgün makale/rehber
- ürün veya hizmet sayfası
- değerli kategori
- forum konusu
- hesaplama aracı

Dizine girmesini istemeyebileceğimiz sayfalar:
- yazdırma sürümü
- arama sonucu
- sıralama/filtre URL’si
- kullanıcı paneli
- giriş/kayıt
- geçici test sayfası
- RSS/Atom
- aynı içeriğin alternatif URL’si

Teknik yardımcı URL’yi zorla indexletmeye çalışmak yerine doğru canonical/noindex davranışını korumak gerekir.

2) Search Console’da URL Denetimi nasıl yapılır?

Search Console’a girin.

Üstteki “URL’leri denetleyin” alanına tam adresi yapıştırın.

Örnek:
Kod:
https://siteadi.com/ornek-sayfa/

Enter’a basın.

Karşınıza iki farklı veri türü çıkabilir:

Google Dizini: Google’ın son bildiği durum.
Canlı Test: Sayfanın şu anki teknik durumu.

Eski raporda noindex görünüp canlı testte sorun görünmemesi mümkündür. Bu durumda rapor güncellenmeyi bekliyor olabilir.

3) “Canlı URL’yi Test Et” ne zaman kullanılmalı?

Sayfada yakın zamanda değişiklik yaptıysanız kullanın.

Sağ üstte:
CANLI URL’Yİ TEST ET

butonuna basın.

Test sonunda özellikle şunlara bakın:

- URL Google tarafından kullanılabilir mi?
- Sayfa dizine eklenebilir mi?
- robots.txt izin veriyor mu?
- noindex var mı?
- sayfa başarıyla getirildi mi?

Canlı test “dizine eklenebilir” diyorsa teknik engel büyük ölçüde kalkmıştır.

4) noindex nasıl kontrol edilir?

Sayfayı tarayıcıda açın.

Windows/Linux:
Kod:
Ctrl + U

Mac:
Kod:
Command + Option + U

Kaynak kodunda arayın:

Kod:
noindex

Şuna benzer bir satır varsa:

Kod:
<meta name="robots" content="noindex,follow">

Google’ın sayfayı dizine almaması beklenir.

Ama noindex yalnız HTML meta etiketiyle gelmez. HTTP başlığında da olabilir:

Kod:
X-Robots-Tag: noindex

Bunu tarayıcı geliştirici araçları, curl veya sunucu başlık testiyle kontrol edebilirsiniz.

5) canonical nasıl kontrol edilir?

Kaynak kodunda:

Kod:
canonical

araması yapın.

Beklenen örnek:

Kod:
<link rel="canonical" href="https://siteadi.com/ornek-sayfa/">

Eğer sayfa kendi URL’si yerine başka bir URL’yi canonical gösteriyorsa Google diğer adresi esas sayfa olarak seçebilir.

Özellikle:
- filtre,
- sıralama,
- yazdırma,
- post/lastpost,
- parametreli URL

gibi alternatiflerde bu normal olabilir.

6) Sitemap kontrolü nasıl yapılır?

Search Console:
Dizin oluşturma → Site Haritaları

alanına gidin.

Sitemap başarılı mı bakın.

Sonra sitemap dosyasını tarayıcıda açıp URL’nin gerçekten listelenip listelenmediğini kontrol edin.

Önemli: sitemap’e yalnız canonical ve indexlenmesini istediğiniz URL’leri koymak daha sağlıklıdır. Parametreli kopyaları sitemap’e eklemeyin.

7) İç bağlantı var mı?

Google bir URL’yi yalnız sitemap’te görmekle yetinmez. Site içinde anlamlı bir yerden bağlantı gelmesi de önemlidir.

Kontrol edin:

- ana kategori link veriyor mu?
- ilgili rehber link veriyor mu?
- breadcrumb içinde mi?
- başka bir içerikten doğal bağlantı var mı?

“Yetim sayfa” olarak kalan içerikler daha zayıf keşfedilebilir.

8) İçerik gerçekten ayrı bir değer sunuyor mu?

“Tarandı fakat dizine eklenmedi” sorununun önemli kısmı teknik değil, içerik tarafında olabilir.

Şunları sorgulayın:

- başka bir sayfayla neredeyse aynı mı?
- sadece 3-4 cümle mi?
- başlık var ama soruyu gerçekten cevaplıyor mu?
- kullanıcı o sayfaya geldiğinde işlemini tamamlayabiliyor mu?
- otomatik üretilmiş ama fayda eklemeyen metin mi?
- aynı anahtar kelimeyi hedefleyen başka güçlü URL var mı?

Google’ın “aynı şeyi anlatan ikinci sayfa” yerine tek bir URL’yi seçmesi normaldir.

9) HTTP durum kodunu kontrol edin

Sayfa gerçekten 200 dönmeli.

301/302 ise yönlendirmeli URL’dir.
404/410 ise dizine alınmaz.
5xx ise sunucu hatası vardır.

Komut satırı erişiminiz varsa:

Kod:
curl -I https://siteadi.com/ornek-sayfa/

Windows’ta curl çoğu güncel sürümde hazır gelir. SSH yoksa çevrimiçi HTTP header kontrol araçları veya tarayıcı geliştirici araçları kullanılabilir.

10) “Dizine eklenmesini iste” ne zaman kullanılmalı?

Şu kontroller geçildikten sonra:

- URL gerçek içerik
- 200 durum kodu
- noindex yok
- canonical doğru
- sitemap doğru
- içerik yeterli
- iç bağlantı var
- canlı test dizine eklenebilir

Search Console URL Denetimi ekranında:
DİZİNE EKLENMESİNİ İSTE

butonuna bir kez basın.

Aynı URL’yi sürekli tekrar göndermek önceliğini artırmaz.

11) Sonra ne kadar beklemeli?

Sabit bir süre yoktur. Yeni veya düşük otoriteli sitelerde tarama/indexleme daha yavaş olabilir. Birkaç saat içinde de olabilir, günler veya daha uzun da sürebilir.

Tekrar kontrol ederken yalnız “index oldu mu?” değil, Search Console’daki son tarama tarihi ve canonical bilgisini de karşılaştırın.

12) Hızlı teşhis tablosu

Kod:
URL gerçek içerik mi? EVET/HAYIR HTTP 200 mü? EVET/HAYIR noindex var mı? EVET/HAYIR canonical kendisi mi? EVET/HAYIR sitemap'te var mı? EVET/HAYIR iç link var mı? EVET/HAYIR canlı test başarılı mı? EVET/HAYIR içerik özgün ve yeterli mi? EVET/HAYIR

Google Search Console’a yeni başlayanlar için:
Google Search Console ne işe yarar?

Sizde “Tarandı - şu anda dizine eklenmedi” en çok hangi sayfa tipinde çıkıyor? URL’yi paylaşmadan sayfa türünü ve canlı test sonucunu yazarsanız birlikte teşhis edebiliriz.

Dataweb editoryal sürüm: derin anlatım v1.0.0]]> <![CDATA[ROAS Kaç Olmalı? 2x, 3x ve 4x ROAS Gerçekte Ne Anlama Gelir?]]> https://dataweb.com.tr/forum/thread-42.html Wed, 02 Sep 2026 13:07:03 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-42.html
Bu nedenle önce ROAS’ın nasıl hesaplandığını, sonra kendi başabaş seviyenizi bulmak gerekir.

1) ROAS tam olarak nedir?

Formül:

Kod:
ROAS = Reklama Atfedilen Gelir / Reklam Harcaması

Örnek:

Kod:
Reklam harcaması: 5.000 TL Reklama atfedilen gelir: 20.000 TL ROAS = 20.000 / 5.000 = 4x

Yani reklama harcanan her 1 TL için reklam platformu 4 TL gelir atfetmiş olur.

Kendi verinizle hesaplamak için:
Dataweb ROAS Hesaplama Aracı

2) 4x ROAS neden otomatik olarak “çok iyi” değildir?

İki işletme düşünelim.

İşletme A
- ürün satış fiyatı: 1.000 TL
- brüt kâr marjı: %20

İşletme B
- satış fiyatı: 1.000 TL
- brüt kâr marjı: %70

Her iki işletme de 4x ROAS görüyor olabilir. Fakat A işletmesinde reklamdan önce elde edilen brüt katkı çok daha düşük olduğu için 4x bile yetersiz kalabilir. B işletmesi ise aynı ROAS seviyesinde çok daha rahat kâr bırakabilir.

Bu nedenle “rakibim 3 ROAS ile reklam veriyor, ben de 3 hedeflemeliyim” yaklaşımı sağlıklı değildir.

3) Basitleştirilmiş başabaş ROAS nasıl bulunur?

Yalnız brüt kâr marjını kullanarak teorik bir eşik hesaplanabilir:

Kod:
Başabaş ROAS = 1 / Brüt Kâr Marjı

Örneğin brüt kâr marjı %40 ise:

Kod:
1 / 0,40 = 2,50x

Bu, diğer değişken giderler yokmuş gibi düşünülen basitleştirilmiş başabaş seviyesidir.

Ama e-ticarette ayrıca:
- pazaryeri komisyonu,
- kargo,
- ödeme komisyonu,
- iade,
- paketleme,
- kupon/indirim,
- operasyon

gibi maliyetler varsa gerçek başabaş ROAS daha yüksek olabilir.

4) Google Ads’te gördüğünüz ROAS ile gerçek işletme ROAS’ı neden farklı olabilir?

Reklam platformunun raporu “reklama atfedilen gelir” üzerinden çalışır. Şunları kontrol edin:
  • Atıf penceresi kaç gün?
  • Satış farklı cihazdan gerçekleştiğinde nasıl eşleniyor?
  • İade edilen siparişler gelirden düşüyor mu?
  • KDV dahil mi, hariç mi raporlanıyor?
  • Kargo geliri satış değerine dahil mi?
  • Bir sipariş birden fazla kampanyaya atfediliyor mu?

Örneğin Google Ads 100.000 TL gelir gösterirken ERP veya muhasebe sisteminde bu siparişlerin 15.000 TL’si iade edilmiş olabilir. Bu durumda yalnız reklam panelindeki ROAS’a bakmak yanıltıcı olur.

5) Hedef ROAS nasıl belirlenir?

Şu sırayla gidin:

  1. Ürün veya hizmetin gerçek brüt marjını bulun.
  2. Değişken maliyetleri çıkarın.
  3. Başabaş seviyeyi hesaplayın.
  4. İşletmenin büyüme hedefini belirleyin.
  5. Yeni müşteri ile mevcut müşteri değerini ayırın.
  6. Kampanya türüne göre farklı hedef kullanın.

Örneğin marka araması yapan kullanıcı zaten sizi arıyorsa marka kampanyasının ROAS’ı çok yüksek çıkabilir. Soğuk kitleye yeni müşteri bulan kampanyada daha düşük ROAS kabul edilebilir. İkisini aynı hedefle değerlendirmek doğru değildir.

6) 2x, 3x ve 4x ROAS pratikte ne anlatır?

2x ROAS
Her 1 TL reklama 2 TL gelir. Marj düşükse zarar ihtimali yüksektir; yüksek marjlı veya yeni müşteri edinimine yatırım yapan işletmelerde kabul edilebilir olabilir.

3x ROAS
Her 1 TL reklama 3 TL gelir. “Orta” diye düşünülmemeli; yine gerçek maliyet yapısı belirleyicidir.

4x ROAS
Her 1 TL reklama 4 TL gelir. Pek çok işletmede iyi görünebilir, fakat net kârı kanıtlamaz.

7) Günlük kontrol tablosu nasıl tutulabilir?

Basit bir tablo açın:

Kod:
Tarih Reklam harcaması Atfedilen gelir ROAS Sipariş sayısı İade tutarı Ürün maliyeti Kargo Komisyon Gerçek katkı

Böylece “ROAS yükseldi” ile “işletmenin gerçek katkısı yükseldi” ifadelerinin aynı olup olmadığını görebilirsiniz.

8) Ne zaman daha düşük ROAS bilinçli olarak kabul edilebilir?

- yeni müşteri edinimi
- abonelik modeli
- tekrar satın alma oranı yüksek ürünler
- yeni pazara giriş
- stok eritme
- yeni ürün testi

gibi durumlarda ilk sipariş ROAS’ı düşük tutulabilir. Ama bunun için müşteri yaşam boyu değeri veya tekrar satın alma verisinin gerçekten ölçülmesi gerekir.

Kısa karar çerçevesi

“ROAS kaç olmalı?” yerine şu soruyu sorun:

Alıntı:Benim maliyet yapımda, bu kampanya türünde ve bu müşteri grubunda sürdürülebilir ROAS kaç olmalı?

ROAS formülünü, başabaş ROAS’ı ve ROI farkını daha ayrıntılı anlattığımız rehber:
ROAS nedir, nasıl hesaplanır?

Sizde hedef ROAS belirlerken yalnız reklam paneline mi bakıyorsunuz, yoksa ürün maliyeti ve iade verisini de aynı tabloda birleştiriyor musunuz?

Dataweb editoryal sürüm: derin anlatım v1.0.0]]>
Bu nedenle önce ROAS’ın nasıl hesaplandığını, sonra kendi başabaş seviyenizi bulmak gerekir.

1) ROAS tam olarak nedir?

Formül:

Kod:
ROAS = Reklama Atfedilen Gelir / Reklam Harcaması

Örnek:

Kod:
Reklam harcaması: 5.000 TL Reklama atfedilen gelir: 20.000 TL ROAS = 20.000 / 5.000 = 4x

Yani reklama harcanan her 1 TL için reklam platformu 4 TL gelir atfetmiş olur.

Kendi verinizle hesaplamak için:
Dataweb ROAS Hesaplama Aracı

2) 4x ROAS neden otomatik olarak “çok iyi” değildir?

İki işletme düşünelim.

İşletme A
- ürün satış fiyatı: 1.000 TL
- brüt kâr marjı: %20

İşletme B
- satış fiyatı: 1.000 TL
- brüt kâr marjı: %70

Her iki işletme de 4x ROAS görüyor olabilir. Fakat A işletmesinde reklamdan önce elde edilen brüt katkı çok daha düşük olduğu için 4x bile yetersiz kalabilir. B işletmesi ise aynı ROAS seviyesinde çok daha rahat kâr bırakabilir.

Bu nedenle “rakibim 3 ROAS ile reklam veriyor, ben de 3 hedeflemeliyim” yaklaşımı sağlıklı değildir.

3) Basitleştirilmiş başabaş ROAS nasıl bulunur?

Yalnız brüt kâr marjını kullanarak teorik bir eşik hesaplanabilir:

Kod:
Başabaş ROAS = 1 / Brüt Kâr Marjı

Örneğin brüt kâr marjı %40 ise:

Kod:
1 / 0,40 = 2,50x

Bu, diğer değişken giderler yokmuş gibi düşünülen basitleştirilmiş başabaş seviyesidir.

Ama e-ticarette ayrıca:
- pazaryeri komisyonu,
- kargo,
- ödeme komisyonu,
- iade,
- paketleme,
- kupon/indirim,
- operasyon

gibi maliyetler varsa gerçek başabaş ROAS daha yüksek olabilir.

4) Google Ads’te gördüğünüz ROAS ile gerçek işletme ROAS’ı neden farklı olabilir?

Reklam platformunun raporu “reklama atfedilen gelir” üzerinden çalışır. Şunları kontrol edin:
  • Atıf penceresi kaç gün?
  • Satış farklı cihazdan gerçekleştiğinde nasıl eşleniyor?
  • İade edilen siparişler gelirden düşüyor mu?
  • KDV dahil mi, hariç mi raporlanıyor?
  • Kargo geliri satış değerine dahil mi?
  • Bir sipariş birden fazla kampanyaya atfediliyor mu?

Örneğin Google Ads 100.000 TL gelir gösterirken ERP veya muhasebe sisteminde bu siparişlerin 15.000 TL’si iade edilmiş olabilir. Bu durumda yalnız reklam panelindeki ROAS’a bakmak yanıltıcı olur.

5) Hedef ROAS nasıl belirlenir?

Şu sırayla gidin:

  1. Ürün veya hizmetin gerçek brüt marjını bulun.
  2. Değişken maliyetleri çıkarın.
  3. Başabaş seviyeyi hesaplayın.
  4. İşletmenin büyüme hedefini belirleyin.
  5. Yeni müşteri ile mevcut müşteri değerini ayırın.
  6. Kampanya türüne göre farklı hedef kullanın.

Örneğin marka araması yapan kullanıcı zaten sizi arıyorsa marka kampanyasının ROAS’ı çok yüksek çıkabilir. Soğuk kitleye yeni müşteri bulan kampanyada daha düşük ROAS kabul edilebilir. İkisini aynı hedefle değerlendirmek doğru değildir.

6) 2x, 3x ve 4x ROAS pratikte ne anlatır?

2x ROAS
Her 1 TL reklama 2 TL gelir. Marj düşükse zarar ihtimali yüksektir; yüksek marjlı veya yeni müşteri edinimine yatırım yapan işletmelerde kabul edilebilir olabilir.

3x ROAS
Her 1 TL reklama 3 TL gelir. “Orta” diye düşünülmemeli; yine gerçek maliyet yapısı belirleyicidir.

4x ROAS
Her 1 TL reklama 4 TL gelir. Pek çok işletmede iyi görünebilir, fakat net kârı kanıtlamaz.

7) Günlük kontrol tablosu nasıl tutulabilir?

Basit bir tablo açın:

Kod:
Tarih Reklam harcaması Atfedilen gelir ROAS Sipariş sayısı İade tutarı Ürün maliyeti Kargo Komisyon Gerçek katkı

Böylece “ROAS yükseldi” ile “işletmenin gerçek katkısı yükseldi” ifadelerinin aynı olup olmadığını görebilirsiniz.

8) Ne zaman daha düşük ROAS bilinçli olarak kabul edilebilir?

- yeni müşteri edinimi
- abonelik modeli
- tekrar satın alma oranı yüksek ürünler
- yeni pazara giriş
- stok eritme
- yeni ürün testi

gibi durumlarda ilk sipariş ROAS’ı düşük tutulabilir. Ama bunun için müşteri yaşam boyu değeri veya tekrar satın alma verisinin gerçekten ölçülmesi gerekir.

Kısa karar çerçevesi

“ROAS kaç olmalı?” yerine şu soruyu sorun:

Alıntı:Benim maliyet yapımda, bu kampanya türünde ve bu müşteri grubunda sürdürülebilir ROAS kaç olmalı?

ROAS formülünü, başabaş ROAS’ı ve ROI farkını daha ayrıntılı anlattığımız rehber:
ROAS nedir, nasıl hesaplanır?

Sizde hedef ROAS belirlerken yalnız reklam paneline mi bakıyorsunuz, yoksa ürün maliyeti ve iade verisini de aynı tabloda birleştiriyor musunuz?

Dataweb editoryal sürüm: derin anlatım v1.0.0]]> <![CDATA[3D Secure Olmadan Ödeme Yapılır mı? Sanal POS'ta 3D Secure Zorunlu mu?]]> https://dataweb.com.tr/forum/thread-41.html Wed, 02 Sep 2026 13:07:03 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-41.html
Bu konuyu yalnız “açık/kapalı” şeklinde düşünmek yanıltıcı olabilir. Banka, ödeme kuruluşu, kart şeması, işlem riski, tutar, işyeri sözleşmesi ve kullanılan ödeme altyapısı akışı değiştirebilir. Bu nedenle aşağıdaki adımlar, genel bir kontrol listesi olarak düşünülmelidir; kendi sağlayıcınızın güncel sözleşmesi ve teknik dokümantasyonu ayrıca kontrol edilmelidir.

1) Önce 3D Secure ile provizyonun aynı şey olmadığını ayırın

3D Secure aşaması kart sahibinin doğrulanmasına yöneliktir. Provizyon ise bankanın işlemi finansal olarak onaylayıp onaylamamasıdır.

Örneğin kullanıcı 3D Secure ekranında doğrulamayı başarıyla tamamlayabilir ama:
- kart limiti yetersiz olabilir,
- banka işlemi riskli bulabilir,
- kart internet alışverişine kapalı olabilir,
- işlem banka tarafından başka bir nedenle reddedilebilir.

Bu yüzden “3D geçti, ödeme kesin başarılıdır” şeklinde düşünmeyin. Teknik entegrasyonda hem doğrulama sonucunu hem ödeme/provizyon sonucunu ayrı ayrı kaydedin.

2) Kullandığınız sanal POS’ta 3D Secure seçeneği nereden kontrol edilir?

Ödeme kuruluşunuzun veya bankanızın yönetim paneline girin. Genellikle şu menülerden birinde bulunur:

- Ayarlar
- Ödeme Ayarları
- Güvenlik
- 3D Secure / 3DS
- Risk Ayarları
- Sanal POS Ayarları

Burada “zorunlu”, “isteğe bağlı”, “işlem bazlı”, “risk bazlı” veya benzeri bir seçenek görebilirsiniz. Hiçbir seçenek görünmüyorsa destek ekibine şu üç soruyu sorun:

Kod:
1. Hesabımda 3D Secure'siz işlem teknik olarak açık mı? 2. Hangi işlemler otomatik olarak 3D Secure'a yönlendiriliyor? 3. 3D Secure kullanılmayan işlemlerde itiraz/chargeback süreci nasıl işliyor?

Yanıtı yazılı olarak alın. Çünkü panel ayarı ile sözleşmedeki risk/sorumluluk hükümleri aynı şey olmayabilir.

3) Entegrasyon tarafında neye bakılmalı?

API kullanıyorsanız ödeme isteğinde 3D Secure akışını belirleyen alanları bulun. Sağlayıcıya göre alan adları farklı olabilir. Örneğin “three_d_secure”, “3ds”, “secure”, “payment_flow” veya benzeri bir parametre görebilirsiniz.

Dokümantasyonda özellikle şunları arayın:

- 3D Secure başlatma isteği
- geri dönüş / callback URL’si
- başarılı ve başarısız doğrulama kodları
- timeout senaryosu
- ödeme/provizyon isteğinin ne zaman gönderileceği
- webhook bildirimi
- aynı siparişin iki kez tahsil edilmesini engelleyen idempotency mantığı

Test ortamında en az şu senaryoları deneyin:
  • 3D doğrulama başarılı + ödeme başarılı
  • 3D doğrulama başarılı + ödeme reddedildi
  • 3D doğrulama başarısız
  • Kullanıcı doğrulama ekranını kapattı
  • İşlem timeout oldu
  • Aynı sipariş tekrar gönderildi

4) 3D Secure’siz akış dönüşümü artırır mı?

Daha az adım bazı işletmelerde ödeme tamamlama oranını artırabilir; ancak bunu varsaymak yerine ölçmek gerekir. Çünkü kullanıcı kitlesi, mobil cihaz oranı, banka dağılımı ve ürün tipi sonucu değiştirebilir.

Ölçmeniz gereken temel değerler:

- ödeme sayfasına gelen kullanıcı
- ödeme denemesi
- 3D ekranına giden kullanıcı
- 3D doğrulamayı tamamlayan kullanıcı
- provizyonu geçen işlem
- başarısız işlem kodları
- itiraz/chargeback oranı
- dolandırıcılık nedeniyle iptal edilen işlemler

Örneğin 1.000 ödeme denemesinin 100 tanesi 3D ekranında terk ediliyorsa önce “3D’yi kapatalım” demek yerine; mobil akış, sayfa hızı, banka dönüş ekranı ve hata mesajları da incelenmelidir.

5) “3D Secure zorunlu mu?” sorusuna neden tek cümleyle cevap vermiyoruz?

Çünkü ödeme akışı sağlayıcıya, bankaya, işlem tipine ve güncel güvenlik/risk kurallarına göre değişebilir. Bir sağlayıcı hesabınızda 3D Secure’siz işleme izin verirken başka bir sağlayıcı veya banka bunu sınırlayabilir. Ayrıca sağlayıcının teknik olarak izin vermesi, her işlem için aynı risk ve sorumluluk yapısının oluşacağı anlamına gelmez.

Bu nedenle en sağlıklı kontrol:

  1. Sağlayıcının güncel teknik dokümantasyonunu açın.
  2. İşyeri sözleşmesindeki 3D Secure ve itiraz maddelerini okuyun.
  3. Paneldeki güvenlik/risk ayarlarını kontrol edin.
  4. Destekten yazılı teyit alın.
  5. Test ortamında akışı deneyin.
  6. Canlıda ödeme başarısı ve itiraz oranını düzenli ölçün.

6) Sadece komisyon oranına bakarak sanal POS seçmeyin

3D Secure akışının yanında şunlar da önemlidir:

- ödeme başarı oranı
- banka hata kodlarının açıklığı
- taksit desteği
- iade ve kısmi iade
- webhook güvenilirliği
- API dokümantasyonu
- mutabakat raporları
- teknik destek kalitesi
- fraud/risk araçları

Bu başlıkların tamamını şu rehberde topladık:
Sanal POS seçerken nelere dikkat edilmeli?

3D Secure konusunda hazırlanan detaylı rehber yayımlandığında bu konuya da bağlanacak.

Kısa kontrol listesi

Bir sağlayıcıyı değerlendirirken şu soruların cevaplarını yazılı hale getirin:

Kod:
3D Secure zorunlu mu? İşlem bazlı değişebiliyor mu? 3D'siz işlem destekleniyor mu? Başarısız 3D sonucunda ne oluyor? Provizyon ayrı mı takip ediliyor? Webhook geliyor mu? Chargeback/itiraz süreci nasıl? Test ortamı var mı?

Siz hangi banka veya ödeme kuruluşunu kullanıyorsunuz? Panelinizde 3D Secure ayarı nasıl görünüyor ve özellikle mobilde ödeme tamamlama oranında fark gözlemlediniz mi?

Dataweb editoryal sürüm: derin anlatım v1.0.0]]>
Bu konuyu yalnız “açık/kapalı” şeklinde düşünmek yanıltıcı olabilir. Banka, ödeme kuruluşu, kart şeması, işlem riski, tutar, işyeri sözleşmesi ve kullanılan ödeme altyapısı akışı değiştirebilir. Bu nedenle aşağıdaki adımlar, genel bir kontrol listesi olarak düşünülmelidir; kendi sağlayıcınızın güncel sözleşmesi ve teknik dokümantasyonu ayrıca kontrol edilmelidir.

1) Önce 3D Secure ile provizyonun aynı şey olmadığını ayırın

3D Secure aşaması kart sahibinin doğrulanmasına yöneliktir. Provizyon ise bankanın işlemi finansal olarak onaylayıp onaylamamasıdır.

Örneğin kullanıcı 3D Secure ekranında doğrulamayı başarıyla tamamlayabilir ama:
- kart limiti yetersiz olabilir,
- banka işlemi riskli bulabilir,
- kart internet alışverişine kapalı olabilir,
- işlem banka tarafından başka bir nedenle reddedilebilir.

Bu yüzden “3D geçti, ödeme kesin başarılıdır” şeklinde düşünmeyin. Teknik entegrasyonda hem doğrulama sonucunu hem ödeme/provizyon sonucunu ayrı ayrı kaydedin.

2) Kullandığınız sanal POS’ta 3D Secure seçeneği nereden kontrol edilir?

Ödeme kuruluşunuzun veya bankanızın yönetim paneline girin. Genellikle şu menülerden birinde bulunur:

- Ayarlar
- Ödeme Ayarları
- Güvenlik
- 3D Secure / 3DS
- Risk Ayarları
- Sanal POS Ayarları

Burada “zorunlu”, “isteğe bağlı”, “işlem bazlı”, “risk bazlı” veya benzeri bir seçenek görebilirsiniz. Hiçbir seçenek görünmüyorsa destek ekibine şu üç soruyu sorun:

Kod:
1. Hesabımda 3D Secure'siz işlem teknik olarak açık mı? 2. Hangi işlemler otomatik olarak 3D Secure'a yönlendiriliyor? 3. 3D Secure kullanılmayan işlemlerde itiraz/chargeback süreci nasıl işliyor?

Yanıtı yazılı olarak alın. Çünkü panel ayarı ile sözleşmedeki risk/sorumluluk hükümleri aynı şey olmayabilir.

3) Entegrasyon tarafında neye bakılmalı?

API kullanıyorsanız ödeme isteğinde 3D Secure akışını belirleyen alanları bulun. Sağlayıcıya göre alan adları farklı olabilir. Örneğin “three_d_secure”, “3ds”, “secure”, “payment_flow” veya benzeri bir parametre görebilirsiniz.

Dokümantasyonda özellikle şunları arayın:

- 3D Secure başlatma isteği
- geri dönüş / callback URL’si
- başarılı ve başarısız doğrulama kodları
- timeout senaryosu
- ödeme/provizyon isteğinin ne zaman gönderileceği
- webhook bildirimi
- aynı siparişin iki kez tahsil edilmesini engelleyen idempotency mantığı

Test ortamında en az şu senaryoları deneyin:
  • 3D doğrulama başarılı + ödeme başarılı
  • 3D doğrulama başarılı + ödeme reddedildi
  • 3D doğrulama başarısız
  • Kullanıcı doğrulama ekranını kapattı
  • İşlem timeout oldu
  • Aynı sipariş tekrar gönderildi

4) 3D Secure’siz akış dönüşümü artırır mı?

Daha az adım bazı işletmelerde ödeme tamamlama oranını artırabilir; ancak bunu varsaymak yerine ölçmek gerekir. Çünkü kullanıcı kitlesi, mobil cihaz oranı, banka dağılımı ve ürün tipi sonucu değiştirebilir.

Ölçmeniz gereken temel değerler:

- ödeme sayfasına gelen kullanıcı
- ödeme denemesi
- 3D ekranına giden kullanıcı
- 3D doğrulamayı tamamlayan kullanıcı
- provizyonu geçen işlem
- başarısız işlem kodları
- itiraz/chargeback oranı
- dolandırıcılık nedeniyle iptal edilen işlemler

Örneğin 1.000 ödeme denemesinin 100 tanesi 3D ekranında terk ediliyorsa önce “3D’yi kapatalım” demek yerine; mobil akış, sayfa hızı, banka dönüş ekranı ve hata mesajları da incelenmelidir.

5) “3D Secure zorunlu mu?” sorusuna neden tek cümleyle cevap vermiyoruz?

Çünkü ödeme akışı sağlayıcıya, bankaya, işlem tipine ve güncel güvenlik/risk kurallarına göre değişebilir. Bir sağlayıcı hesabınızda 3D Secure’siz işleme izin verirken başka bir sağlayıcı veya banka bunu sınırlayabilir. Ayrıca sağlayıcının teknik olarak izin vermesi, her işlem için aynı risk ve sorumluluk yapısının oluşacağı anlamına gelmez.

Bu nedenle en sağlıklı kontrol:

  1. Sağlayıcının güncel teknik dokümantasyonunu açın.
  2. İşyeri sözleşmesindeki 3D Secure ve itiraz maddelerini okuyun.
  3. Paneldeki güvenlik/risk ayarlarını kontrol edin.
  4. Destekten yazılı teyit alın.
  5. Test ortamında akışı deneyin.
  6. Canlıda ödeme başarısı ve itiraz oranını düzenli ölçün.

6) Sadece komisyon oranına bakarak sanal POS seçmeyin

3D Secure akışının yanında şunlar da önemlidir:

- ödeme başarı oranı
- banka hata kodlarının açıklığı
- taksit desteği
- iade ve kısmi iade
- webhook güvenilirliği
- API dokümantasyonu
- mutabakat raporları
- teknik destek kalitesi
- fraud/risk araçları

Bu başlıkların tamamını şu rehberde topladık:
Sanal POS seçerken nelere dikkat edilmeli?

3D Secure konusunda hazırlanan detaylı rehber yayımlandığında bu konuya da bağlanacak.

Kısa kontrol listesi

Bir sağlayıcıyı değerlendirirken şu soruların cevaplarını yazılı hale getirin:

Kod:
3D Secure zorunlu mu? İşlem bazlı değişebiliyor mu? 3D'siz işlem destekleniyor mu? Başarısız 3D sonucunda ne oluyor? Provizyon ayrı mı takip ediliyor? Webhook geliyor mu? Chargeback/itiraz süreci nasıl? Test ortamı var mı?

Siz hangi banka veya ödeme kuruluşunu kullanıyorsunuz? Panelinizde 3D Secure ayarı nasıl görünüyor ve özellikle mobilde ödeme tamamlama oranında fark gözlemlediniz mi?

Dataweb editoryal sürüm: derin anlatım v1.0.0]]> <![CDATA[Yeni Bir İşletmede İlk Müşteriyi Bulmak mı, Düzenli Müşteri Kazanmak mı Daha Zor?]]> https://dataweb.com.tr/forum/thread-40.html Tue, 25 Aug 2026 11:20:49 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-40.html
Sizin deneyiminizde hangisi daha zor oldu?
  • İlk müşteriyi bulmak
  • İlk satışı gerçekleştirmek
  • Müşterinin tekrar satın almasını sağlamak
  • Tavsiye yoluyla yeni müşteri kazanmak
  • Reklamdan kârlı müşteri elde etmek
  • Fiyat rekabetiyle baş etmek
  • Güven oluşturmak
  • Düzenli teklif / talep akışı oluşturmak
  • Başka bir aşama

Özellikle kendi işini kuran veya küçük bir işletme yönetenlerin gerçek deneyimleri faydalı olur.

Mümkünse sektörünüzü ve müşterilerinizi ağırlıklı olarak hangi kanaldan bulduğunuzu da yazabilirsiniz: Google, sosyal medya, pazaryeri, referans, fiziksel mağaza, doğrudan satış vb.

Firma adı, ciro veya özel müşteri bilgisi paylaşmanız gerekmiyor.

Amaç “en iyi satış kanalı hangisi?” demek değil; yeni işletmelerin müşteri kazanma sürecinde gerçekten hangi aşamada zorlandığını görmek.]]>
Sizin deneyiminizde hangisi daha zor oldu?
  • İlk müşteriyi bulmak
  • İlk satışı gerçekleştirmek
  • Müşterinin tekrar satın almasını sağlamak
  • Tavsiye yoluyla yeni müşteri kazanmak
  • Reklamdan kârlı müşteri elde etmek
  • Fiyat rekabetiyle baş etmek
  • Güven oluşturmak
  • Düzenli teklif / talep akışı oluşturmak
  • Başka bir aşama

Özellikle kendi işini kuran veya küçük bir işletme yönetenlerin gerçek deneyimleri faydalı olur.

Mümkünse sektörünüzü ve müşterilerinizi ağırlıklı olarak hangi kanaldan bulduğunuzu da yazabilirsiniz: Google, sosyal medya, pazaryeri, referans, fiziksel mağaza, doğrudan satış vb.

Firma adı, ciro veya özel müşteri bilgisi paylaşmanız gerekmiyor.

Amaç “en iyi satış kanalı hangisi?” demek değil; yeni işletmelerin müşteri kazanma sürecinde gerçekten hangi aşamada zorlandığını görmek.]]> <![CDATA[KOBİ'lerde Nakit Akışını En Çok Bozan Kalem Sizce Hangisi?]]> https://dataweb.com.tr/forum/thread-39.html Tue, 25 Aug 2026 11:08:08 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-39.html
Sizin deneyiminizde nakit akışını en çok bozan kalem hangisi?
  • Geç tahsilat
  • Vadeli satışlar
  • Yüksek stok maliyeti
  • Kredi / finansman ödemeleri
  • Personel giderleri
  • Kira ve sabit giderler
  • Vergi / SGK ödemeleri
  • Sezonluk gelir dalgalanmaları
  • Plansız yatırım harcamaları
  • Müşteri kaybı / ciro düşüşü
  • Başka bir neden

Mümkünse sektörünüzü de belirtin. Firma adı, ciro veya hassas finansal bilgi paylaşmanız gerekmiyor.

Özellikle şu tür deneyimler faydalı olur:
  • “Kârlıyız ama nakitte zorlanıyoruz” durumu
  • Tahsilat vadelerinin işletmeye etkisi
  • Kredi kullanımının rahatlatıcı mı yoksa baskılayıcı mı olduğu
  • Stok ile nakit arasında denge kurma
  • Sabit giderlerin ne zaman riskli hale geldiği

Amaç yatırım tavsiyesi vermek değil; KOBİ'lerin nakit akışında hangi problemlerin gerçekten daha yaygın olduğunu görmek.]]>
Sizin deneyiminizde nakit akışını en çok bozan kalem hangisi?
  • Geç tahsilat
  • Vadeli satışlar
  • Yüksek stok maliyeti
  • Kredi / finansman ödemeleri
  • Personel giderleri
  • Kira ve sabit giderler
  • Vergi / SGK ödemeleri
  • Sezonluk gelir dalgalanmaları
  • Plansız yatırım harcamaları
  • Müşteri kaybı / ciro düşüşü
  • Başka bir neden

Mümkünse sektörünüzü de belirtin. Firma adı, ciro veya hassas finansal bilgi paylaşmanız gerekmiyor.

Özellikle şu tür deneyimler faydalı olur:
  • “Kârlıyız ama nakitte zorlanıyoruz” durumu
  • Tahsilat vadelerinin işletmeye etkisi
  • Kredi kullanımının rahatlatıcı mı yoksa baskılayıcı mı olduğu
  • Stok ile nakit arasında denge kurma
  • Sabit giderlerin ne zaman riskli hale geldiği

Amaç yatırım tavsiyesi vermek değil; KOBİ'lerin nakit akışında hangi problemlerin gerçekten daha yaygın olduğunu görmek.]]> <![CDATA[Bir KOBİ Web Sitesinde Ziyaretçiyi En Çok Kaçıran Hata Sizce Ne?]]> https://dataweb.com.tr/forum/thread-38.html Tue, 25 Aug 2026 11:06:26 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-38.html
Sizin deneyiminizde bir KOBİ web sitesinde ziyaretçiyi en çok kaçıran hata hangisi?
  • Yavaş açılan sayfalar
  • Mobil görünümün kötü olması
  • Eski / amatör tasarım
  • İletişim bilgilerinin zor bulunması
  • Net bir fiyat veya teklif sürecinin olmaması
  • Çok fazla popup / reklam
  • Güven vermeyen içerik veya görseller
  • Karmaşık menü
  • Zayıf ürün / hizmet açıklamaları
  • SSL veya güvenlik sorunları
  • Gereksiz uzun formlar
  • Başka bir hata

Web sitesi sahibi, geliştirici veya müşteri olarak yaşadığınız gerçek örnekleri paylaşabilirsiniz.

Özellikle “Siteye girdim ama şu nedenle firmayla iletişime geçmedim” türündeki kullanıcı deneyimleri de değerli olur.

Amaç tasarım zevklerini tartışmak değil; bir KOBİ web sitesinin müşteri kaybetmesine gerçekten neden olan problemleri ortaya çıkarmak.]]>
Sizin deneyiminizde bir KOBİ web sitesinde ziyaretçiyi en çok kaçıran hata hangisi?
  • Yavaş açılan sayfalar
  • Mobil görünümün kötü olması
  • Eski / amatör tasarım
  • İletişim bilgilerinin zor bulunması
  • Net bir fiyat veya teklif sürecinin olmaması
  • Çok fazla popup / reklam
  • Güven vermeyen içerik veya görseller
  • Karmaşık menü
  • Zayıf ürün / hizmet açıklamaları
  • SSL veya güvenlik sorunları
  • Gereksiz uzun formlar
  • Başka bir hata

Web sitesi sahibi, geliştirici veya müşteri olarak yaşadığınız gerçek örnekleri paylaşabilirsiniz.

Özellikle “Siteye girdim ama şu nedenle firmayla iletişime geçmedim” türündeki kullanıcı deneyimleri de değerli olur.

Amaç tasarım zevklerini tartışmak değil; bir KOBİ web sitesinin müşteri kaybetmesine gerçekten neden olan problemleri ortaya çıkarmak.]]> <![CDATA[2026'da Google Ads'te KOBİ'lerin En Büyük Sorunu Sizce Ne?]]> https://dataweb.com.tr/forum/thread-37.html Tue, 25 Aug 2026 11:04:27 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-37.html 2026 itibarıyla sizin deneyiminizde en büyük sorun hangisi?
  • Tıklama maliyetlerinin yükselmesi
  • Rekabetin artması
  • Dönüşüm alamamak
  • Yanlış veya alakasız tıklamalar
  • Dönüşüm takibinin doğru çalışmaması
  • Açılış sayfasının yetersiz olması
  • Kampanya kurulumunun karmaşıklığı
  • Ajans / freelancer yönetimi
  • Bütçenin yetersiz kalması
  • Başka bir sorun

Deneyiminiz varsa sektörünüzü ve yaklaşık olarak hangi kampanya türünü kullandığınızı da yazabilirsiniz. Bütçe veya firma adı paylaşmanız gerekmiyor.

Amacımız ajans veya Google Ads eleştirisi yapmak değil; KOBİ'lerin gerçek reklam deneyimlerinden hangi problemlerin daha yaygın olduğunu görmek.]]> 2026 itibarıyla sizin deneyiminizde en büyük sorun hangisi?
  • Tıklama maliyetlerinin yükselmesi
  • Rekabetin artması
  • Dönüşüm alamamak
  • Yanlış veya alakasız tıklamalar
  • Dönüşüm takibinin doğru çalışmaması
  • Açılış sayfasının yetersiz olması
  • Kampanya kurulumunun karmaşıklığı
  • Ajans / freelancer yönetimi
  • Bütçenin yetersiz kalması
  • Başka bir sorun

Deneyiminiz varsa sektörünüzü ve yaklaşık olarak hangi kampanya türünü kullandığınızı da yazabilirsiniz. Bütçe veya firma adı paylaşmanız gerekmiyor.

Amacımız ajans veya Google Ads eleştirisi yapmak değil; KOBİ'lerin gerçek reklam deneyimlerinden hangi problemlerin daha yaygın olduğunu görmek.]]> <![CDATA[2026'da Pazaryeri Satıcılarının En Büyük Maliyeti Sizce Hangisi?]]> https://dataweb.com.tr/forum/thread-36.html Tue, 25 Aug 2026 11:00:36 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-36.html
2026 itibarıyla sizin işletmenizde en fazla yük oluşturan kalem hangisi?
  • Pazaryeri komisyonu
  • Reklam giderleri
  • Kargo
  • İade ve iptaller
  • Kampanya / indirim maliyetleri
  • Ürün tedarik maliyeti
  • Personel ve operasyon
  • Muhasebe / e-fatura / yazılım
  • Başka bir gider

Özellikle Trendyol, Hepsiburada, Amazon Türkiye, n11 veya diğer pazaryerlerinde aktif satış yapanların gerçek deneyimlerini paylaşması faydalı olur.
Mümkünse hangi pazaryerinde satış yaptığınızı ve hangi giderin sizi en çok zorladığını da yazın. Firma adı veya ciro paylaşmanız gerekmiyor.
Amacımız “hangi pazaryeri daha kötü?” tartışması değil; satıcıların gerçek maliyet yapısını birbirinden öğrenebilmesi.]]>
2026 itibarıyla sizin işletmenizde en fazla yük oluşturan kalem hangisi?
  • Pazaryeri komisyonu
  • Reklam giderleri
  • Kargo
  • İade ve iptaller
  • Kampanya / indirim maliyetleri
  • Ürün tedarik maliyeti
  • Personel ve operasyon
  • Muhasebe / e-fatura / yazılım
  • Başka bir gider

Özellikle Trendyol, Hepsiburada, Amazon Türkiye, n11 veya diğer pazaryerlerinde aktif satış yapanların gerçek deneyimlerini paylaşması faydalı olur.
Mümkünse hangi pazaryerinde satış yaptığınızı ve hangi giderin sizi en çok zorladığını da yazın. Firma adı veya ciro paylaşmanız gerekmiyor.
Amacımız “hangi pazaryeri daha kötü?” tartışması değil; satıcıların gerçek maliyet yapısını birbirinden öğrenebilmesi.]]> <![CDATA[Hizmet Alım/Satım — Kurallar ve İlan Formatı]]> https://dataweb.com.tr/forum/thread-35.html Tue, 25 Aug 2026 10:54:51 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-35.html Yayınlanabilecek hizmetler
  • Web tasarım ve yazılım
  • SEO ve dijital pazarlama
  • Grafik tasarım ve kurumsal kimlik
  • E-ticaret hizmetleri
  • Fotoğraf ve video hizmetleri
  • Danışmanlık
  • Kurumsal teknoloji ve dijital dönüşüm hizmetleri
  • Diğer yasal B2B veya bağımsız profesyonel hizmetler

İlan formatı

Hizmet:
Kısa açıklama:
Teslim kapsamı:
Fiyat / başlangıç fiyatı:
Teslim süresi:
Referans / portföy: Varsa.
Fatura durumu: Varsa belirtilebilir.
İletişim: Dataweb özel mesajı önerilir.

Kurallar
  • Personel alımı, iş arama, CV paylaşımı ve çalışan yerleştirme ilanlarına izin verilmez.
  • Yanıltıcı referans, sahte müşteri yorumu veya gerçek dışı garanti verilemez.
  • Yasa dışı veya mevzuata aykırı hizmetler sunulamaz.
  • Aynı hizmet için tekrar tekrar konu açılamaz.
  • Fiyat, teslim ve hizmet kapsamının mümkün olduğunca açık belirtilmesi önerilir.
  • Dataweb kullanıcılar arasındaki sözleşme, ödeme veya teslimatın tarafı ya da garantörü değildir.
  • Şüpheli veya topluluk güvenliğini riske atan ilanlar moderasyon tarafından kaldırılabilir.
]]> Yayınlanabilecek hizmetler
  • Web tasarım ve yazılım
  • SEO ve dijital pazarlama
  • Grafik tasarım ve kurumsal kimlik
  • E-ticaret hizmetleri
  • Fotoğraf ve video hizmetleri
  • Danışmanlık
  • Kurumsal teknoloji ve dijital dönüşüm hizmetleri
  • Diğer yasal B2B veya bağımsız profesyonel hizmetler

İlan formatı

Hizmet:
Kısa açıklama:
Teslim kapsamı:
Fiyat / başlangıç fiyatı:
Teslim süresi:
Referans / portföy: Varsa.
Fatura durumu: Varsa belirtilebilir.
İletişim: Dataweb özel mesajı önerilir.

Kurallar
  • Personel alımı, iş arama, CV paylaşımı ve çalışan yerleştirme ilanlarına izin verilmez.
  • Yanıltıcı referans, sahte müşteri yorumu veya gerçek dışı garanti verilemez.
  • Yasa dışı veya mevzuata aykırı hizmetler sunulamaz.
  • Aynı hizmet için tekrar tekrar konu açılamaz.
  • Fiyat, teslim ve hizmet kapsamının mümkün olduğunca açık belirtilmesi önerilir.
  • Dataweb kullanıcılar arasındaki sözleşme, ödeme veya teslimatın tarafı ya da garantörü değildir.
  • Şüpheli veya topluluk güvenliğini riske atan ilanlar moderasyon tarafından kaldırılabilir.
]]> <![CDATA[Proje & İş Birliği Talepleri — Kurallar ve Talep Formatı]]> https://dataweb.com.tr/forum/thread-34.html Tue, 25 Aug 2026 10:52:37 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-34.html Bu bölümde paylaşılabilecek talepler
  • Web sitesi, e-ticaret sitesi veya yazılım projesi
  • SEO, dijital reklam ve içerik hizmeti
  • Grafik tasarım, kurumsal kimlik, fotoğraf veya video hizmeti
  • E-ticaret entegrasyonu ve teknik geliştirme
  • Muhasebe, danışmanlık ve diğer profesyonel hizmet talepleri
  • Tedarikçi, çözüm ortağı veya B2B iş birliği arayışları
  • Belirli bir çıktı ve kapsamı bulunan bağımsız proje/hizmet talepleri

Bu bölümde yayınlanamaz
  • Personel veya çalışan arama ilanları
  • Tam zamanlı veya yarı zamanlı iş ilanları
  • Maaşlı pozisyon ilanları
  • Vardiyalı çalışma ilanları
  • Stajyer veya çalışan arayışları
  • “İş arıyorum” ilanları
  • CV veya özgeçmiş paylaşımları
  • İşveren ile iş arayanı buluşturmaya yönelik içerikler

İstihdam amaçlı ilanlar için İŞKUR ve mevzuata uygun yetkili istihdam kanalları kullanılmalıdır.

Talep açarken şu bilgileri yazın

Aranan hizmet:
Projenin kısa açıklaması:
Beklenen teslim/çıktı:
Bütçe: Belirtmek istemiyorsanız “Teklif bekliyorum” yazabilirsiniz.
Tahmini süre / teslim tarihi:
Uzaktan / yerinde:
Şehir: Yalnızca yerinde hizmet gerekiyorsa.
Özel gereksinimler:
İletişim tercihi: Dataweb özel mesajı önerilir.

Örnek başlıklar

[Hizmet Aranıyor] WooCommerce ödeme entegrasyonu
[Proje] Kurumsal web sitesi tasarımı için teklif arıyorum
[B2B İş Birliği] E-ticaret firmaları için lojistik çözüm ortağı aranıyor

Genel kurallar
  • Gerçek bir ihtiyaca dayanmayan veya yanıltıcı ilanlar yayınlanamaz.
  • Aynı talep tekrar tekrar açılamaz.
  • Konuyla ilgisiz reklam ve bağlantılar kaldırılabilir.
  • Yasa dışı ürün, hizmet veya faaliyetlere yönelik içerik yayınlanamaz.
  • Başka kişilerin iletişim veya kişisel bilgileri izinsiz paylaşılamaz.
  • Tarafların kapsam, ücret, ödeme, teslim ve sözleşme şartlarını yazılı olarak netleştirmesi önerilir.
  • Dataweb, kullanıcılar arasındaki ticari işlemlerin tarafı, garantörü veya ödeme aracısı değildir.
  • İstihdam ilişkisi doğuran veya çalışan yerleştirmeye yönelik içerikler moderasyon tarafından kaldırılabilir.

Talep sonuçlandığında konu sahibinin konuya “Talep sonuçlandı” şeklinde bilgi eklemesi önerilir.]]> Bu bölümde paylaşılabilecek talepler
  • Web sitesi, e-ticaret sitesi veya yazılım projesi
  • SEO, dijital reklam ve içerik hizmeti
  • Grafik tasarım, kurumsal kimlik, fotoğraf veya video hizmeti
  • E-ticaret entegrasyonu ve teknik geliştirme
  • Muhasebe, danışmanlık ve diğer profesyonel hizmet talepleri
  • Tedarikçi, çözüm ortağı veya B2B iş birliği arayışları
  • Belirli bir çıktı ve kapsamı bulunan bağımsız proje/hizmet talepleri

Bu bölümde yayınlanamaz
  • Personel veya çalışan arama ilanları
  • Tam zamanlı veya yarı zamanlı iş ilanları
  • Maaşlı pozisyon ilanları
  • Vardiyalı çalışma ilanları
  • Stajyer veya çalışan arayışları
  • “İş arıyorum” ilanları
  • CV veya özgeçmiş paylaşımları
  • İşveren ile iş arayanı buluşturmaya yönelik içerikler

İstihdam amaçlı ilanlar için İŞKUR ve mevzuata uygun yetkili istihdam kanalları kullanılmalıdır.

Talep açarken şu bilgileri yazın

Aranan hizmet:
Projenin kısa açıklaması:
Beklenen teslim/çıktı:
Bütçe: Belirtmek istemiyorsanız “Teklif bekliyorum” yazabilirsiniz.
Tahmini süre / teslim tarihi:
Uzaktan / yerinde:
Şehir: Yalnızca yerinde hizmet gerekiyorsa.
Özel gereksinimler:
İletişim tercihi: Dataweb özel mesajı önerilir.

Örnek başlıklar

[Hizmet Aranıyor] WooCommerce ödeme entegrasyonu
[Proje] Kurumsal web sitesi tasarımı için teklif arıyorum
[B2B İş Birliği] E-ticaret firmaları için lojistik çözüm ortağı aranıyor

Genel kurallar
  • Gerçek bir ihtiyaca dayanmayan veya yanıltıcı ilanlar yayınlanamaz.
  • Aynı talep tekrar tekrar açılamaz.
  • Konuyla ilgisiz reklam ve bağlantılar kaldırılabilir.
  • Yasa dışı ürün, hizmet veya faaliyetlere yönelik içerik yayınlanamaz.
  • Başka kişilerin iletişim veya kişisel bilgileri izinsiz paylaşılamaz.
  • Tarafların kapsam, ücret, ödeme, teslim ve sözleşme şartlarını yazılı olarak netleştirmesi önerilir.
  • Dataweb, kullanıcılar arasındaki ticari işlemlerin tarafı, garantörü veya ödeme aracısı değildir.
  • İstihdam ilişkisi doğuran veya çalışan yerleştirmeye yönelik içerikler moderasyon tarafından kaldırılabilir.

Talep sonuçlandığında konu sahibinin konuya “Talep sonuçlandı” şeklinde bilgi eklemesi önerilir.]]> <![CDATA[Sıcak Fırsatlar Bölümü Nasıl Kullanılmalı? Paylaşım Formatı]]> https://dataweb.com.tr/forum/thread-31.html Thu, 20 Aug 2026 11:10:26 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-31.html
Bir fırsat konusu açarken mümkünse:
- Kampanyanın tam adı
- Kimlerin yararlanabileceği
- Başlangıç/bitiş tarihi
- Şartlar ve önemli sınırlamalar
- Resmî veya doğrudan kaynak bağlantısı

ekleyin.

Affiliate veya ticari ilişkiniz varsa bunu mesajda açıkça belirtin. Süresi dolan fırsatlar için konuya güncelleme yazılması, arşivin güvenilir kalmasına yardımcı olur.

Reklam amaçlı toplu link bırakmak yerine gerçekten faydalı fırsatları seçelim.]]>
Bir fırsat konusu açarken mümkünse:
- Kampanyanın tam adı
- Kimlerin yararlanabileceği
- Başlangıç/bitiş tarihi
- Şartlar ve önemli sınırlamalar
- Resmî veya doğrudan kaynak bağlantısı

ekleyin.

Affiliate veya ticari ilişkiniz varsa bunu mesajda açıkça belirtin. Süresi dolan fırsatlar için konuya güncelleme yazılması, arşivin güvenilir kalmasına yardımcı olur.

Reklam amaçlı toplu link bırakmak yerine gerçekten faydalı fırsatları seçelim.]]> <![CDATA[Şirket Nakit Akışında Günlük, Haftalık ve Aylık Hangi Görünüm Ayrılmalı?]]> https://dataweb.com.tr/forum/thread-30.html Thu, 20 Aug 2026 11:10:26 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-30.html
Pratik bir yapı:
- Günlük: banka/kasa ve kritik ödeme
- Haftalık: beklenen tahsilat, maaş, tedarikçi, kredi
- Aylık: işletme gideri, stok yatırımı, vergi ve yatırım planı

Özellikle vadeli satış yapan işletmelerde “satış yapıldı” ile “para hesaba geldi” arasındaki fark büyük olabilir.

Siz nakit akışını kaç haftalık ileri görünümle takip ediyorsunuz?]]>
Pratik bir yapı:
- Günlük: banka/kasa ve kritik ödeme
- Haftalık: beklenen tahsilat, maaş, tedarikçi, kredi
- Aylık: işletme gideri, stok yatırımı, vergi ve yatırım planı

Özellikle vadeli satış yapan işletmelerde “satış yapıldı” ile “para hesaba geldi” arasındaki fark büyük olabilir.

Siz nakit akışını kaç haftalık ileri görünümle takip ediyorsunuz?]]>