Dijital Varlık (Mülk/Hesap) Yönetimi ve Öneriler

Temelde problemin nedenleri olarak uygulamaların niteliklerinin tam olarak kavranamamış olması ve kolaycılık olarak özetlenebilir. Bu yazıda Dijital Mülk Nedir? sorusuyla başlayıp karşılaşılan problemler ve çözümleriyle devam edeceğim. Eğer halihazırda bir sosyal medya kurumsal/marka hesabınız, web sayfanız, hosting alanınız, alan adınız, veri tabanınız… varsa, ki olmaması mümkün değil, bu yazıdaki sorunlar size oldukça tanıdık gelecektir.

Dijital Varlık

Fiziksel ya da dijital ayrımı olmaksızın varlık tanımına baktığımızda, kendine has ya da sonradan atanan bir değere sahip olması kıstasıyla karşılaşıyoruz. Ev, ofis, bilgisayar, yetenek… tüm bunlar ve fazlası varlık olarak nitelendirilebilirler. Dijitalleşen dünyada fiziksel kitaplar elektronik kitaplara, mektuplar e-postalara, fiziksel mağazalar online dükkanlara dönüşmekteler. Yazımızın konusu da dijital değer olarak ifade ettiğimiz fotoğraflar, yazılımlar, web siteleri, e-postala videolar, dökümanlar, hesap bilgileri, anahtarlar gibi dijital varlıkların yönetimi. Burada küçük bir not eklemek uygun olacaktır, örneğin tarayıcıda taranıp ya da fotoğrafı çekilip aslen fiziksel olan bir varlık bilgisayarda PDF ya da TIFF formatına dönüştürüldüğünde, her hangi bir yaratıcı süreç sonucu oluşmadığı durumlarda dokümanlar “dijital değer” olarak nitelendirilmeyebilirler.

Dijital Varlık Yönetimi

Belirttiğim gibi, Facebook, Google Analytics, Google Tag Manager hesaplarınızın, web sayfanızın, domain ve hosting erişimlerinizin olması günümüzde oldukça normal. Şirketler ve ajanslar için ise bu sürecin yönetimi tam bir ızdırap. Değişen çalışanlar, değiştirilen ve/veya güncellenmeyen erişim bilgileri, ID’ler. Müşterilerin genel olarak “işim hallolsun da yeter” diyerek edinmediği bilgiler, hatta edinmemenin ötesinde konuya dair hiçbir fikri ve merakı olmaması da cabası. 10 milyon şifreyi incelediğini söyleyen siber güvenlik şirketi Keeper‘ın verilerine göre, 2016 yılında en çok kullanılan şifrenin 123456 olmasına şaşırmamak gerekiyor. Web servisleri basit şifre kullanımını engelleyerek çeşitli karakterleri zorunlu kılarak bir şekilde önlem alıyorlar, 2 adımlı doğrulama gibi teknolojilerle de güvenlik seviyesi artırılabiliyor. Farklı kaynaklardan sağlanan erişimler bildiriliyor vs. Ancak, yine bir şekilde işin kolay yöntemi tercih ediliyor.

Markalara (Müşterilere) Öneriler

Genel olarak karşılaştığım tüm sorunları anlatmam mümkün değil, ancak yoğunlukla karşılaştığım konular üzerinden genel tavsiyelerle en azından ajans-müşteri ilişkilerinin daha az ızdıraplı hale gelmesine yardımcı olabilir ve sorulara göre yazı içeriğini geliştirebilirim.

Facebook Varlık Yönetimi

Kişi ve marka tarafında Facebook¹ ve Instagram² üzerinden reklam vermek için illa Business³ erişimi tanımlamanız gerekmiyor⁴. Ancak, pixel oluşturma⁵, domain doğrulama⁶, reklam organizasyonu⁷, katalog kurulumu⁸, vb. için Business hesabı oluşturarak Sayfa ilişkilendirmesi yapmanız gerekli. Eğer bir gün dışarıdan kişi ya da ajans desteği almak isterseniz hesap erişimlerini kişi hesaplarıyla yapmamanızı öneririm. Bunun yerine Business hesabı oluşturup Sayfa ilişkilendirmesi yapmalı, Kişi/Ajans’a ait Business hesabını Ortak olarak eklemelisiniz.

Durum 1

Bir kişi ya da Kurum için Business hesabı oluşturulduğuna oluşturan kişi Varlık Sahibi olacaktır. Bu hesap başka bir ortağa devredilemez, yönetici erişimi transfer edilemez. Bu nedenle ajans değişikliklerinde veri kaybı yaşamamak için hesap oluşturma işlemi marka/kişi tarafından gerçekleştirilmeli ve ortaklık üzerinden erişimler sağlanmalıdır.

Durum 2

Özel ve kurumsal ilişkiler nedeniyle hesap erişimleri kişisel hesaplar üzerinden sağlanmamalıdır. Bu nedenle erişim işlemleri Business ID üzerinden yürütülmelidir. Taraflar kendi bünyelerinde erişim yetkilendirmelerini ekibe uygun şekilde yöneteceklerdir.

Durum 3

Müşteri hesap şifreleri paylaşılmamalı. Erişim ve yapılandırmalar TeamViewer gibi uygulamalar kullanılarak müşterinin takip edebileceği şekilde, şifreler paylaşılmamış olarak gerçekleştirilmelidir.

Durum 4

Taraflarda yönetici seviyesinde, en az yönetim kademesinden bir yetkilinin de olduğu en az 2 kişi olmalıdır. Çalışan değişiklikleri gibi durumlarda hesap erişimi de kaybedilebilir.

Durum 5

Erişim sahipleri (kişi, ortaklar, uygulamalar) düzenli olarak kontrol edilmeli, değişikliklerde erişimler düzenlenmelidir. Eski bir çalışanın ya da eski ajansın hala erişim sağlayabiliyor olmasının kimseye faydası olmaz.

Google Tag Manager

Google Tag Manager bünyesinde hem hesap erişimleri hem de custom kodlar yer almakta. Servis entegrasyon sürecini kolaylaştırdığı için hem yönetim hem de performans açısından kritik bir öneme sahip. Ancak, genelde müşteriler ve ajanslar tarafından ya değerlendirilmemekte ya da idareten kullanılmakta. Hesap ve kapsayıcı yönetimiyle oldukça esneklik suna n GTM ile ilgili dikkat edilmesi gereken birkaç konu bulunmakta.

Durum 6

Hesap ile Kapsayıcı farklı özelliklere sahip. Örneğin Müşteriler, Projeler şeklinde bir Hesap alanı oluşturabilir ve kapsayıcı olarak web, app (iOS, Android) vb. erişimlerinizi barındırabilirsiniz. Her marka için (aksi gerekmediği sürece) hesap oluşturmak yönetimi zor bir yapı ortaya çıkaracaktır.

Ajanslarda yetkilendirmeleri Hesap üzerinden tanımladığınızda, kişiler hesap alanı altındaki tüm kapsayıcılara yetkilendirmeleri dahilinde erişebilirler. Ekip dışı bir erişim için ise doğrudan Kapsayıcı üzerinden erişim tanımlanabilir. Böylelikle erişimleri daha rahat kontrol edebilirsiniz.

Durum 7

Google Tag Manager’ın müşteri tarafından oluşturulması ve ajanslara erişim sağlanması en uygun olanı. Çalışma alanları ve sürüm takibi ile gerçekleştirilen işlemler bu sayede rahatlıkla takip edilebilir. Bu aşamada, web sayfanıza yerleştirdiğiniz Google Tag Manager ID’si ile erişim sahibi olduğunuz kapsayıcı ID’sini ve yetkilendirmenizi karşılaştırmanız önemli. Farkında olmayacağınız ve/veya hatalı kurulumları düzenleyebilmeli, gerektiği durumlarda çalışma ortamını değiştirebilmeli, servis entegrasyonlarını pasifleştirebilmelisiniz.

Durum 8

Bir nedenden dolayı bir kapsayıcıdan diğerine geçiş yapmanız gerekebilir. Bu durumda yapılan kurulumlar Dışa Aktar/İçe Aktar ile farklı hesaplar altındaki kapsayıcılara taşınabilir. Ancak bu durumda kapsayıcıya ait ID değeri değişecektir. Bu değişimin web sayfası ve aplikasyonda yer alan ID için uygulanması gerekmektedir.

Google Analytics

Web sayfanız ve uygulamanızdaki kullanıcı hareketlerini takip ve analiz edebileceğiniz, Search Console, Adwords, Adsense, Youtube ile entegre edebileceğiniz Google Analytics sanırım ücretsiz olmasından dolayı oldukça özensiz bir şekilde yönetilmekte. Google Analytics düzenlemeleri başka yazıların konuları. Temelde dikkat edilmesi gereken konular Hesap, Mülk ve Görünüm düzenlemeleriyle ilgili. Google Tag Manager ile benzer şekilde Hesap altında bir çok genel tanımlama (müşteriler, projeler vb.) yapılabilir. Mülk ise benzersiz Google Analytics ID’nizi aldığınız ve her uygulama/web sitesi için yönetim işlemi gerçekleştirdiğiniz alandır. Erişimler hesap üzerinden tanımlanırsa ilgili kişi hesap altındaki tüm mülkleri yetkisi dahilinde kontrol edebilir. Ajans ve müşteri ekiplerinin hesap üzerinden erişime sahip olmaları uygun olacaktır. Ancak, ekip dışından yetkilendirmelerde eğer tüm mülkler söz konusu değilse işlemler mülk bazında yetkilendirmeyle sağlanmalıdır.

Durum 9

Mülk altında birden fazla Görünüm oluşturulabilir. Görünüm verileri göreceğiniz, düzenleyebileceğiniz alandır. Yapılan her işlem gerçekleştirildiği gün itibariyle verilerinizle etkileşime geçecektir. Bu nedenle herhangi bir işlem barındırmayan (filtre vb.) bir Görünüm bulundurmalısınız. Kurulum aşamasında ön tanımlı olarak All Web Site Data adında bir görünüm oluşturulmaktadır. Başta filtreleme olmak üzere veri üzerinde etki yaratacak tüm düzenlemeler için ayrı bir Görünüm daha oluşturulmalıdır. Bu sayede hatalı olabilecek bir düzenlemede diğer Görünüm altında verileri olduğu gibi görme imkanınız olur.

Durum 10

Bir web sitesinde birden fazla Google Analytics hesabı kullanılabilir. Bir network ya da benzer türleri arasında ortak veri kullanımı için tercih edilebilecek bir durum olarak ortak hesaplarda gruplama yapılmalı, cookie’ler buna göre düzenlenmeli (Google Global Tag) ve hesap ilişkilendirmeleri bu bağlamda gerçekleştirilmelidir. Ajanslar ve müşteriler karşılaştırma yapmak için farklı Google Analytics Mülk’lerini kullanmak isteyebilirler. Bu nedenle kurulumlar bu kritere uygun şekilde gerçekleştirilmelidir. Google Tag Manager bu ve benzeri konular için daha da önem kazanmaktadır.

Durum 11

Analiz araçlarının algoritmaları sayılarda farklılıklar ortaya çıkarabilirler. Ek olarak duplicate kurulum, hatalı yerleştirme, JavaScript hataları, session sınırlandırmaları, sayfa yavaşlığı gibi diğer konular da karşılaştırmalarda farklar görüntülenmesine neden olabilir. Bu nedenle kurulum aşamalarında ve düzenli olarak belirli sürelerde kontroller yapılmalıdır. Diğer yandan, Özel Uyarılar ile kritik değişimlerden haberdar olabilirsiniz. Yapılan her düzenleme (tanımlamalar, kampanyalar, teknik düzenlemeler vb. kısacası uygulamanın ve/veya web sayfasının varlığını etkileyen her konu) Google Analytics altında notlandırılmalıdır.

Google Ads

Performans reklamları için kullanılan Google Ads, kişiler, ajanslar ve markalar için ayrı erişimler ve özellikler sunmakta. Genel olarak görev atanması ve ajans ilişkilendirmeleriyle işleyen yapı bazı ajanların kendi geliştirdikleri paneller üzerinden de yönetilebilmektedir. Markalara/müşterilere tavsiyem Google Ads hesaplarını kendi bünyelerinde oluşturmaları ve kişi ve/veya ajanslara yetki vermeleri. Bu şekilde daha doğru bir takip süreci söz konusu olacaktır. Panel erişimleri de bu şekilde sağlanabilmektedir.

Durum 12

Ajanslar kendi geliştirdikleri paneller üzerinden kampanya kurguları ve raporlama yapabilmektedir. Ancak, Google Adwords dışında işleyen bu sistemlerdeki algoritma hataları vb. durumlarda veri aslından farklı şekilde sunuluyor olabilir. Bu ve benzeri durumları kısa sürede fark edebilmek için müşteri tarafından oluşturulmuş bir Adwords hesabı kullanılmalı ve gerektiği zaman karşılaştırma yapılabilmelidir. Oluşurulan panellerin belirli işlemleri pratikleştirmek, otomatize etmek, kullanıcı deneyimini iyileştirmek amacıyla geliştirildiği unutulmamalıdır.

Durum 13

Dönüşüm ve yeniden pazarlama kodlarının dönüşüm olarak tanımlamam etkinliğe bağlı olarak doğru bir şekilde yerleştirildiğinden emin olunmalıdır. Tekrarlı, hatalı sayımların yanlış stratejiler geliştirilmesine neden olabileceği unutulmamalıdır.

Domain (Alan Adı)

Alan adı (www.domain.com) dosyalarınıza (web sayfası vb.) erişmek için kullandığınız kısa yol olarak ifade edilebilir. Alan adı sahibi olmanız aynı zamanda bir web sayfasına ve e-posta hesabına sahip olduğunuz anlamına gelmez. Paket teklifler bu süreci pratikleştirmek için barındırma (hosting) şirketleri tarafından sunulur. Ajanslar aracı kişiler nedeniyle vakit kaybetmemek adına kimi zaman domain, hosting ve kurulum işlemlerini üstlenebilirler. Markalar/müşteriler domain, hosting, e-posta kurulumu gibi işlemleri kendileri yapmalı, ödemeleri kendileri takip etmeli, firma bilgilerini güncel tutmalıdır.

Durum 14

Belirttiğim gibi, kimi zaman domain ve hosting aynı sağlayıcılardan alınabilir ya da kişi ya da ajans tarafından süreç başlatılmış olabilir. Olası bir aksilikte domain erişimini kaybedebilirsiniz. Bu tür durumlarda domain alımının gerçekleştirildiği firma ile marka sahibi olduğunuzu kanıtlayan belgelerle iletişime geçip destek talep edebilirsiniz. Bu ve benzeri süreçlerde web sayfanıza erişim sağlayamamanız, marka/kurumu zarara uğratacak sorunlarla karşılaşmanız mümkün olabilir. Bu nedenle domain yönetimi marka tarafından sağlanmalıdır.

Durum 15

Domain aldığınız firma üzerinden yetkili kişi ataması yapabilirsiniz. Bu sayede yetkilendirmede bulunduğunuz kişi ve/veya ajans temsilcisi değişiklikleri kolaylıkla sağlanabilir, kritik düzenlemelerde hızlıca çözüm üretilebilir.

Hosting (Barındırma)

Alan adınızın internet tarayıcısına yazılması sonrasında erişilen web sayfanızın bulunduğu alandır. Çoğu zaman veri tabınınız ve e-postalarınız da hosting alanınızda saklanır. Ayrı bir e-posta ve veri tabanı sunucusu kullanıyor olduğunuzda hosting için söz konusu olan durumlar yine benzerlik taşıyabilir.

Durum 16

Barındırma alanı da yine marka/müşteri tarafından satın alınmalı ve takip edilmelidir. Kota aşımı, süre sonu, saldırı vb. durumlardan ilk olarak müşteri haberdar olmalı, yetkilendirmelerle kişi ve/veya ajanslar erişim sağlayabilmelidir. Eğer domain ile aynı sağlayıcı tarafından barındırma işlemi gerçekleştirilmiyorsa her iki işlem için takvim üzerinden yenileme tarihleri ayrı şekilde takip edilmelidir.

Durum 17

Kişi ve ajanslara farklı FTP hesapları oluşturulmalı ve ilgili oldukları konulara göre dizin işlemleri belirtilmelidir. Bu sayede olası teknik ve güvenlik sorunlarından korunulabilir. Çalışma sürecinin tamamlanmasının ardından ilgili FTP hesabı silinerek yetkilendirmeler takip edilebilir.

Durum 18

Veri tabanı, CPanel vb. erişimler için de yetkilendirmeler yapılabilmektedir. Her web sayfası için ayrı tablo, kullanıcı ve şifre oluşturulmalıdır. Bu sayede olası teknik ve güvenlik sorunlarının önüne geçilebilir.

Durum 19

Düzenli yedekleme yapılmalı, mümkünse ayrı bir bulut depo alanında yedekler tutulmalıdır.

Web Sayfası/Uygulama

Hazır ya da ihtiyaçlarınız için özel olarak geliştirilmiş bir web sayfası/uygulama sahibi olabilirsiniz. Marka/müşteri olarak yönetim, kullanıcı atama, veri tabanı (kullanılıyorsa) gibi konular hakkında bilgi sahibi olmalı ve süreci güncel bir şekilde takip etmelisiniz. Admin (yönetici) erişimi size ait olmalı kişi/ajans için yetkilendirmeler göreve uygun şekilde sizin tarafınızdan sağlanmalı ve takip edilmelidir.

Durum 20

Sunucu üzerinden yedekleme kurulmuş olmalı ve mümkünse bir bulut depo alanında güncel olarak tutulmalıdır. Aksi söz konusu değilse sunucular belirli dönemlerde yedekleme yapmaktadır. Ancak bu yedeklemeler güncellik taşımayabilir. Bu nedenle ayrı bir yedekleme tanımlanmalı ve takip edilmelidir.

Durum 21

Web sayfasıyla ilgili düzenlemeler ilgili kişilere konunun gereksinimlerine göre (ftp, veri tabanı, panel düzenleme vb.) değerlendirilerek sunulmalıdır.

Durum 22

Hazır bir sistem kullanılmışsa (Örneğin WordPress) ve otomatik güncelleme söz konusuysa eklentiler ve arayüz üzerinde özel olarak yapılmış düzenlemeler kaybedilebilir. Bu nedenle yapılmış işlemler not edilmiş olmalı, yapılacak düzenlemeler bu notlarla karşılaştırılarak yönetilmelidir.

E-Posta Hesapları ve Erişimler

E-posta hesapları hosting üzerinden yönetiliyor olabilir. Bu durumda Cpanel vb. bir panel kullanılıyor olacaktır. Müşteri/marka yönetici olarak hesap ve kota işlemlerini gerçekleştirebilmeli, yetkili atayabilmelidir.

Durum 23

Web sayfası, hosting kurulumları ajans ya da kişi tarafından oluşturulduğunda iletişim sorunu yaşanması durumunda ihtiyacınız olan kontroller söz konusu olmayacaktır. Bu nedenle yönetim erişimi marka/müşteri tarafından sağlanmalıdır.

Durum 24

Harici bir e-posta servisi kullanılıyorsa hesap açılışı ve yönetim müşteri/markaya ait olmalı, gerekli durumlarda yetkilendirmelerle diğer kişiler sürece dahil edilmelidir.

Örnek Süreç

Son olarak karşılaştığım bir sorun, müşteriye ait tüm dijital varlıkların ajans bünyesinde oluşturulması üzerineydi. Hazırlanan web sayfalarından sosyal medya hesaplarına, pazarlama ve analiz araçlarından e-posta yönetimine kadar bir çok işlem ajans hesapları altında hazırlanmış ve müşteriye erişim verilmişti. Süreç konusunda bilgi sahibi olmayan müşteri ajans değişikliğine gittiğinde ajans hesapları altındaki tüm erişimlerini geriye yönelik olarak kaybetti. Bir çok konuda bilgisiz olan müşteri yeni ajansa süreç konusunda yardımcı olamadığı için geçiş süreci oldukça sancılı ilerledi, kampanyalarda performans düşüşleri ve veri kayıpları söz konusu oldu. Ajans bünyesindeki çalışan değişiklikleri nedeniyle kullanılan servislerin belirlenmesinde de sorunlar yaşandı. Müşterinin günlük rutini takip edilerek kullanılan servisler belirlendi, erişimler takip edildi. Hesap aktarımı söz konusu olmayan servislerde yeniden hesaplar bu defa müşteriye ait olacak şekilde yeniden oluşturuldu. Süreçten bir örnek vermek gerekirse; Müşteri web sitesi üzerinden gerçekleşen e-posta gönderimlerinin Yandex üzerinden sağlandığını, aynı şekilde kurumsal e-postaların Yandex’in Kurumsal özelliği ile entegre olduğunu bilmemekteydi. Ajans ile konuyu paylaşıp nedenini sorduğumda, bu kararın Yandex arayüzünün daha hoş olmasından dolayı verildiğini öğrendim. Hesap ajans bünyesinde oluşturulduğu için aktarım söz konusu olmamaktaydı. Bu nedenle önceki Kurum ID altındaki e-postalar indirildi ve müşteri için Passport tanımlanarak yeni bir Kurum ID oluşturuldu ve hesaplar ilişkilendirildi. Bu ve benzeri tüm konularda müşteri bilgilendirildi. Çoğunlukla bu süreç oldukça karışık olarak nitelendirilmekte. Ancak, söz konusu olabilecek zararlar hesaba katıldığında konuyla ilgili en az 2 kişinin marka/müşteri/ajans bünyesinde yer alması kritik. Peki, bu kadar farklı hesap ve erişim bilgisi nasıl takip edilecek?

Erişimlerin Takip Edilmesi ve Paylaşımı

Bir çok servis için farklı şifreler kullanılması bir zorunluluk. Bu süreç ayrıca kişiye ait olmayan, en az 2 yetkili kişi tarafından erişilebilen merkezi bir kurumsal e-posta adresi üzerinden yürütülmeli. Peki, bu kadar şifre nasıl takip edilmeli? Bu bilgilerin başta Word belgesi, proje yönetim araçları, Excel tablosu, defter… gibi bir çok şekilde kayıt altında tutulduğunu gördüm. Ancak, yoğunluk her servis için aynı şifrenin kullanılması ve e-posta ortamında iletilmesi şeklindeydi. Tavsiyem GMail (Google Analytics, Tag Manager, Adwords gibi Google servisleri için), Yandex (Kurumsal e-posta, Metrica vb. kurulumlar için) gibi servisler üzerinden kurumsal bir hesap erişimi sağlanması ve servis kurulumlarında kullanılması yönünde. Mümkünse, yıkarıda belirttiğim gibi tüm üyelik ve hesap işlemlerinde kurumsal e-posta adresiniz, telefon numaranız kullanılmalı ve 2 adımlı doğrulama açık olmalı. Yedek hesap olarak diğer yetkili iş arkadaşınızın e-posta adresi ve ardından GMail, Yandex hesaplarınız eklenebilir. Tüm bu hesapların yönetiminde ise çeşitli araçlardan faydalanılabilir. Bu şekilde aynı şifre kullanımı, tek dosya üzerinden tüm hesaplara erişimin mümkün olması gibi sorunların önüne geçilebilir. Önerebileceğim araçlar şöyle:

KeePass

Keepass ücretsiz olarak 2003 yılından beri kullanılan bir şifre yönetim uygulaması⁹. Android ve iOS üzerinden yüklenebilecek uygulamalarla (mobil uygulamalar resmi olarak geliştirilmemekte) farklı şekilde erişimler yönetilebilmekte.

Lastpass

Kurumsal, aile, bireysel gibi ihtiyaçlara göre kullanım yapıları sunan Lastpass ücretli alternatiflerden biri¹⁰. Web, mobil, akıllı saat gibi bir çok şekilde kullanılabilen uygulama erişim aktarma (One-to-many sharing) aşamalarında oldukça pratik bir süreç sağlamakta. Bir uygulamada birden fazla kullanıcının olduğu durumlarda 1Password’ün aksine, her kullanıcı için kayıt oluşturabilmekte.

1Password

Lastpass takibi olan 1Password benzer şekilde kişisel, kurumsal ve aile erişimleri sağlamakta¹¹.

Enpass

Enpass masaüstü uygulamada ücretsiz, ancak çoklu platform erişimlerinde ücretli uygulamalardan biri ve Lastpass ile 1Password‘e benzer işlevlere sahip¹². Platform erişimlerinin genişliğiyle öne çıkmasına karşın çoklu kullanıcılar için (aile, ekip, kurum vb.) grup özelliği sunmamakta.

Tek Oturum Açma (Single sign-on)

Single sign-on çoklu erişim kontrolü çözümlerinden biri. Birden çok ilişkili, ancak bağımsız yazılım sisteminin erişim denetimi sağlayan Single Sign-On (SSO) sayesinde bir kullanıcı ilgili birkaç sisteme erişmek için tek bir kullanıcı kimliği ve şifre ile giriş yapabilmekte. Web siteleriniz ve mümkünse uygulamalar arasında SSO giriş ile parola kontrolünü ve güvenliği merkezi bir hale getirebilirsiniz. Özellikle, firmanıza bağlı pek çok web sitesi ve/veya uygulama var ve çalışanlarını veya müşterileriniz her web sayfası ve uygulama için ayrı ayrı oturum ve hesap yönetimi yapmak durumundalar ise SSO ile bu süreci daha pratik hale getirmek isteyebilirsiniz.