Dub.co'dan Elido'ya Geçiş: İçe Aktarıcı Gerçekte Ne Yapıyor

Elido'nun Dub.co içe aktarıcısı, bağlantılarınızı Dub'ın REST API'si üzerinden istek başına 100 olarak okur ve onları tek bir Elido alan adında aynı slug ile oluşturur. Slug'ı, hedef URL'yi, başlığı ve etiket adlarını taşır. Klasörleri, arşivlenmiş bağlantıları, tıklama geçmişini veya herhangi bir bağlantı ayarını taşımaz. Bir geçişi planlıyorsanız önemli olan gerçekler bunlar.

Bu yazının önceki bir sürümü, Dub klasörlerinin etiketlere düzleştirildiğini iddia ediyordu. Bu güncelleme için içe aktarıcıyı yeniden okudum ve bu yanlıştı: kod klasörleri hiç okumuyor. Bu sürüm, services/api-core/internal/imports/dub.go dosyasının bugün ne yaptığını, Dub'ın yayımlanmış API belirtimine karşı kontrol ederek anlatıyor (erişim 2026-10-02).

İçe aktarıcı Dub'dan ne istiyor

İşçi, anahtarınızı bearer jetonu olarak kullanarak GET https://api.dub.co/links?page=N&pageSize=100 isteği gönderir. Dub'ın API anahtarı belgelerine göre (erişim 2026-10-02), bir anahtar tek bir çalışma alanına bağlıdır ve salt okunur olarak oluşturulabilir. Bu içe aktarma için salt okunur bir anahtar yeterlidir, çünkü işçi yalnızca bağlantıları listeler ve Dub'a asla yazmaz.

Yanıt düz bir JSON dizisidir. "Daha fazlası var" bayrağı yoktur; bu yüzden işçi, bir sayfa 100 öğeden kısa ya da boş dönene kadar sayfa istemeye devam eder:

if len(links) == 0 { break }
// ... import each link ...
if len(links) < dubPageSize { break } // last page
page++

Dub'ın kendi belirtiminden bir uyarı: page parametresi, startingAfter ile imleç tabanlı sayfalama lehine kullanımdan kaldırılmış olarak işaretlenmiştir. Bugün hâlâ çalışıyor ve pageSize en fazla 100 kabul ediyor. Dub page parametresini kaldırırsa içe aktarıcıda küçük bir değişiklik gerekecek ve bunun sessiz veri kaybı yerine açık bir HTTP hatasıyla başarısız bir iş olarak görünmesini beklerim.

Dub'ın hız sınırları sayfası (erişim 2026-10-02), Free planda dakikada 60 ve Pro'da 600 istek listeler. İçe aktarıcı, istekler arasında bağlantıları Postgres'e tek tek ekler; bu yüzden pratikte Free sınırına yaklaşmaz. Yeniden deneme de yoktur: bir HTTP 429 ya da 200 dışındaki herhangi bir yanıt, işi mesajda durum koduyla birlikte başarısız olarak bitirir.

Elido'ya ne iniyor, alan alan

Bir Dub bağlantısındaki geri kalan her şey yere düşer: açıklama, sosyal önizleme görseli, son kullanma tarihi, parola, coğrafya ve cihaz hedeflemesi, UTM alanları, iOS ve Android hedefleri, dönüşüm takibi bayrakları. Bir bağlantı bunlardan herhangi birine dayanıyorsa, içe aktarmadan sonra yeniden kurun. Elido'nun hedefleme için kendi akıllı bağlantı kuralları var, ama Dub'ın kurallarını otomatik olarak eşleyen hiçbir şey yok.

Klasörler, arşivlenmiş bağlantılar ve alan adları

Üç Dub kavramı ele alınmıyor ve her biri sizi şaşırtabilir.

Klasörler. Dub'ın bağlantı şemasında klasör yalnızca bir folderId dizesi olarak görünür. İçe aktarıcının bunun için bir alanı yok ve klasör adlarını çözmek için ikinci bir çağrı yapmıyor. Elido'da klasör değil etiket var; bu yüzden gelecekteki bir içe aktarıcı bile onları düzleştirmek zorunda kalırdı. Bugün klasör yapısı kayboluyor. Önemliyse, başlamadan önce her slug için klasörü not edin, ardından içe aktarılan grubu (imported:dub üzerinde filtreleyin) elle veya API ile etiketleyin.

Arşivlenmiş bağlantılar. Dub'ın liste uç noktası, varsayılanı false olan bir showArchived parametresi alır. İçe aktarıcı onu hiç ayarlamaz; bu yüzden arşivlenmiş bağlantılar döndürülmez ve içe aktarılmaz. Bir geçiş için makul bir varsayılandır, ancak eski kampanya bağlantılarını bilerek arşivde tutuyorsanız bunu bilmelisiniz.

Bağlantı alan adları. Bir Dub çalışma alanı birkaç alan adında bağlantı tutabilir. İçe aktarıcı hepsini okur, domain alanını yok sayar ve her bağlantıyı seçtiğiniz tek Elido alan adında oluşturur. İki Dub alan adı aynı key'i kullanıyorsa, ikincisi bir çakışmaya takılır. Sonrasında ne olacağını çakışma stratejisi belirler; bu yüzden onu bunu düşünerek seçin.

Çakışmalar, sınırlar ve işçi sözleşmesi

İşi başlatırken bir çakışma stratejisi seçersiniz:

• suffix, mylink-2, mylink-3 gibi -50'ye kadar dener, sonra o bağlantıdan vazgeçer ve onu başarısız sayar.
• skip, mevcut Elido bağlantısına dokunmaz ve slug'ı atlandı olarak günlüğe kaydeder.
• fail, ilk çakışmada tüm işi durdurur.

Çalışma başına işçi 50.000 bağlantıda (MaxLinksPerImport) ya da 30 dakika sonra (ImportRunBudget), hangisi önce gelirse, durur. İlerleme her 50 bağlantıda bir kaydedilir ve pano onu sorgular. Hata günlüğü en fazla 1.000 kayıt tutar. Her slug kontrolü, (domain_id, slug) üzerinde tek bir dizinli aramadır.

Dub içe aktarmalarını büyük bir hesap üzerinde kıyaslamadım; bu yüzden dakikada kaç bağlantı olduğuna dair bir rakam vermeyeceğim. Döngü, 100 bağlantılık bir HTTP sayfası ve ardından 100 sıralı eklemedir; bu yüzden süre, Dub'ın ne kadar hızlı yanıtladığına ve veritabanınıza göre ölçeklenir. Önce küçük bir çalışma alanıyla test edin.

Jeton yönetimi ve bir dağıtımda ne olur

Anahtar, POST /imports/dub isteğinin gövdesinde taşınır, çalışan işçinin belleğinde tutulur ve asla saklanmaz: iş satırının source_token_id alanı boş kalır. İşin source_filter sütununa yalnızca isteğe bağlı workspace_id metni girer.

İşçi, HTTP isteğinden context.WithoutCancel ile ayrılmış bir goroutine içinde çalışır. Bu, onu yanıttan sonra da hayatta tutar ve aynı zamanda bir dağıtımın ya da yeniden başlatmanın onu çalışma ortasında öldürebileceği anlamına gelir. Bir zamanlayıcı işi her 5 dakikada bir çalışır ve 30 dakika boyunca ilerleme kaydetmeyen her running içe aktarmayı başarısız olarak işaretler. Yeniden çalıştırmak suffix altında güvenlidir (zaten içe aktarılmış her şeyin -2 kopyalarını alırsınız) ve skip altında da (zaten içe aktarılmış slug'lar atlanır). Henüz hiçbir şey son sayfadan devam etmiyor.

Sentetik verili bir demo çalışma alanındaki bağlantı listesi. İçe aktarmadan sonra grubu bulmak için imported:dub etiketiyle filtreleyin.

Çalıştırmadan önce kısa bir kontrol listesi

1. Dub çalışma alanınızda salt okunur bir API anahtarı oluşturun.
2. Tutmak istediğiniz arşivlenmiş bağlantıları arşivden çıkarın ve güvendiğiniz klasör yapısını not edin.
3. Hedef alan adını Elido'da ekleyin ve tüm Dub alan adlarının bu tekine çökeceğini bilerek skip veya suffix seçin.
4. İçe aktarmayı pano entegrasyon sayfasından ya da token, target_domain_id ve conflict_strategy ile POST /imports/dub üzerinden çalıştırın.
5. Slug'ları ve hedefleri Dub'la karşılaştırarak örnekleme yapın, ardından sahibi olduğunuz her özel alan adı için DNS'i güncelleyin. Bitly geçiş kılavuzu DNS sırasını anlatıyor; bu sıra her satıcı için aynıdır.

Hâlâ taşınıp taşınmayacağınıza karar veriyorsanız, Elido vs Dub planları ve özellikleri karşılaştırıyor, URL kısaltıcılar için GDPR ise veri yerleşimi tarafını açıklıyor. Satıcıya yönelik adım adım anlatım Dub geçiş sayfasında yer alıyor.

Blogda İlgili Yazılar

• Elido vs Dub: SSO, dönüşüm takibi, AB yerleşimi
• Dub alternatifleri: karşılaştırılan 6 bağlantı yönetimi platformu
• Bitly geçişini yayına almak: bir işçi, bir jeton, 30 dakikalık bütçe
• Rebrandly geçişini yayına almak: sayfa başına 25 sayfalama
• Short.io geçişini yayına almak: sayfa başına 150 ile alan adı bazlı sayfalama